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

[Roland McGrath <roland at hack dot frob dot com>]

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

Right.  Personally I would prefer to avoid the camelP.h naming style.
Between the other two I don't have a particular preference except that we
should move towards consistent conventions and knowing what they mean.
e.g. perhaps foo-private.h should only be for things that really should be
private to the foo subsystem, while foo-internal.h is for things in the foo
subsystem that are internal to libc put public across subsystems.  Or
perhaps vice versa.  Or perhaps we don't need both of those.  Whatever.
But choosing conventions, describing them clearly, and using them
consistently is the goal.

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

I guess I do, since we've identified 6 categories and there's only two of
them that I'm not 100% sure need to be distinct.

> 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?

Tentatively yes, but maybe don't bother?  That is, I don't really know off
hand how much we have in categories E and F today or how much we're likely
to get.  If there is little enough it might not be worth distinguishing
them.  Personally I don't mind having clearly-defined categories with very
few members and being pedantic about putting things in the right categories
even when that means some of the headers declare one or two things.  But I
wouldn't want to insist on that.


Thanks,
Roland