Re: __* in installed headers

[Roland McGrath <roland@frob.com>]

> This is not what I said is guaranteed.  What is guaranteed is that the
> internally used headers are a superset of the externally used headers.
> I know that changing only one interface is troublesome.  But let's see
> the case:

That you answer in this way means I have failed to communicate my
fundamental point.  The principle of conservatism is that we can never
predictively enumerate the cases that may arise.  Where humans or the C
preprocessor, let alone both, are involved, there can be no certainty of
formal notions like a pure superset.  When I said it makes me uncomfortable
to have the headers used when compiling libc and the headers used by user
code not be the exact same files, that is exactly what I meant.  I can't
predict the problem; I'm just quite sure that noone can positively rule out
problems.  A little gratuitous paranoia is good for the digestion.

> Well, I've made this change after some silence.  I've read your mail
> after I made all the changes.

I was on vacation last week and busy working in my real job the week
before, and wasn't tracking things real closely.  But it seemed a bit quick
to me.  It is not a big deal.

> This was not intended to offend anybody, it's just that from my point of
> view the disadvantages were not that critical.  Plus, the current
> solution of placing the prototypes in the files in include/ need not be
> the final solution.

Of course, and anyway it is not the most important thing in the world.  But
we all know too well how things that have already gone in tend to stay
around while people forget about finding a better solution and worry about
more pressing things.

> I just want to have the real headers to be clean and this is something I
> think is critical.  I don't agree that adding a warning is enough.  We've
> seen this in the past, people are too stupid.

I agree; but it doesn't really matter until a 2.1 release, so this week
instead of next isn't very critical.  

> So, if we can come up with a better solution then the duplication of
> the prototyeps as it is done now, fine.  

The duplication of the prototypes is not the primary concern for me, in
fact.  As long as the *_alias et macros in libc-symbols.h are using the GCC
magic instead of asm magic, the compiler should catch mismatches.  It is a
bit of bother to maintain though.  Someone could write a script to massage
the user headers copying every __P decl and munging the symbol name; or
maybe do some hack with protoize.

> But the installed headers should have the form they have now.  They are
> part of the documented interface and therefore need to be accurate.

No argument here.