This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] malloc: Run fork handler as late as possible [BZ #19431]
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 12 Apr 2016 11:46:43 -0700 (PDT)
- Subject: Re: [PATCH] malloc: Run fork handler as late as possible [BZ #19431]
- Authentication-results: sourceware.org; auth=none
- References: <56BBAF3D dot 5030905 at redhat dot com> <1455559833 dot 20971 dot 11 dot camel at localhost dot localdomain> <56C5EE32 dot 1020605 at redhat dot com> <1460485015 dot 3869 dot 267 dot camel at localhost dot localdomain>
> > > Should this perhaps be malloc-internal.h to match libc-internal.h?
> >
> > We also have libio/libioP.h, and include/malloc.h. But I think a
> > separate header makes sense if its contents is truly internal.
> >
> > What are the preferences here?
>
> I think having an internal header is good, but I can't give a definitive
> reply regarding what the project prefers.
We have a clear preference for keeping internal things in internal headers.
Some of the existing wrapper headers conflate pure wrapper issues (macro
versions of things, hidden_proto, etc) with providing internal interfaces.
But we want to avoid doing that in the future. Cleaning up existing
violations of this principle would certainly be welcome.