Date: Thu, 2 Apr 2020 14:34:42 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Steve Wills <swills@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Time to svn rm include/malloc.h Message-ID: <20200402113442.GL1992@kib.kiev.ua> In-Reply-To: <CANCZdfq9KTM9ob74ad20gn6wEMteZdSgBV26y4-=7KDPfGs7BA@mail.gmail.com> References: <CANCZdfr19HgeMLc=XwZPCGecSV0pwMw52SrbgXnKYO9vAHfLyg@mail.gmail.com> <6dbfb7cd-b4c8-dea8-8fc5-43e2b89e352d@FreeBSD.org> <20200331210258.GJ1992@kib.kiev.ua> <CANCZdfq9KTM9ob74ad20gn6wEMteZdSgBV26y4-=7KDPfGs7BA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 31, 2020 at 03:48:54PM -0600, Warner Losh wrote: > On Tue, Mar 31, 2020 at 3:03 PM Konstantin Belousov <kostikbel@gmail.com> > wrote: > > > On Tue, Mar 31, 2020 at 04:01:23PM -0400, Steve Wills wrote: > > > Yeah, a lot of ports have things like: > > > > > > sed -e 's/malloc.h/stdlib.h/' *.[ch] > > > > > > because they have autotools that check for malloc.h existence and > > include it > > > if it exists, so you end up with things like: > > > > > > ... > > > #include <stdlib.h> > > > ... > > > #if HAVE_MALLOC_H > > > #include <stdlib.h> > > > #endif > > > ... > > > > > > which ends up harmless, but sub-optimal. > > > > > So wouldn't it be more useful to remove warning and either include > > stdlib.h or provide some parts of malloc-related defines, esp. the > > non-portable bits from jemalloc ? > > > > We've provided an error for the past 20 years. And a warning for the last > 24 years. Nobody is usefully using it today. In fact, it is getting in the > way, which is why we should just remove it entirely. The file is not useful as provided by us today, sure. But other OSes, namely LInux, do use it for allocator extensions features, and newer Linux-only software tends to include it unconditionally. > > > > We are not in position to teach third-party sw developers good manners. > > > > Autotools would do the right thing if we just remove this file. We're being > bad by having it and having it's inclusion be an error. It's not required > by any standard, and automation out there does the right thing when it's > not present, so we should complete the process started in 1994 by ache and > just remove it. Autotools do the right thing if somebody bothered to add corresponding fragment and than paint the whole source tree with #if HAVE_MALLOC_H. I had to do this for some large unfinished project, and this is not easy to sell to maintainers, generally. > > Warner > > > > > Steve > > > > > > > > > On 3/31/20 3:50 PM, Warner Losh wrote: > > > > We started warning in 1994 that malloc.h was an obsolete relic of a > > bygon > > > > era. It was almost removed from FreeBSD 2.0. It's time to remove it > > because > > > > it causes more harm than good to ports these days. 25 years of advance > > > > warning should be enough, I'd say. > > > > > > > > To that end, I plan on removing it from -current on April 15th. > > > > > > > > Is there any reason I shouldn't do this? > > > > > > > > Warner > > > > _______________________________________________ > > > > freebsd-arch@freebsd.org mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > > > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org > > " > > > > > > > _______________________________________________ > > > freebsd-arch@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200402113442.GL1992>