[PATCH] malloc: Run fork handler as late as possible [BZ #19431]

[Florian Weimer]

On 04/12/2016 08:46 PM, Roland McGrath wrote:
>>>> 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.

Great, so include/malloc.h is out, and malloc-private.h, 
malloc-internal.h and mallocP.h are still in the race. :)

Just to clarify, do you see a future where we have about five different 
headers per subsystem?

   A. the installed header, subsystem/subsystem.h
   B. its wrapper, include/subsystem.h
   C. architecture-specific overrides, subsystem/bits/subsystem.h,
      to be installed
   D. architecture-specific overrides, not installed
      (must not be in bits/ per previous discussion)
   E. a header for libc-internal access across subsystem boundaries,
      name undecided (often mixed into include/subsystem.h today,
      but libioP.h is an existing example for such a separate header)
   F. a header for subsystem-internal declarations shared by
      translation units in the subsystem, naming convention undecided
      (but there is precedent subsystem-private.h, e.g. pty-private.h)

The new header in this patch is in category F (used across subsystems, 
internal to libc).  Should we keep this separate from E and use a 
separate naming convention?

Florian