Re: __* in installed headers

[Zack Weinberg <zack@rabi.phys.columbia.edu>]

On Mon, 17 Aug 1998 05:21:48 -0400, Roland McGrath wrote:
>> >> This is why I suggested wrappers with #defines to be used when compiling
>> >> libc.  It would ensure getting the right symbol and would allow even
>> >> internal sources to be written with the public symbol names.
>> >
>> >I think that is a dangerous way to go.  For the headers, it is arguably
>> >even worse on the issue that I have been harping on of using the same
>> >headers for compiling the library as will be installed for users.  
>> 
>> I don't follow - can you explain why this is worse?
>
>Because #define'ing symbols that appear in a header before #include'ing
>that header is a subtle thing that can potentially change a lot of things
>in bizarre ways.  Of course we do not expect this to be the case, but the
>fact that there are so many possibilities makes it dangerous.

Right.  I didn't think of it in those terms.

>> You want to use the same headers to compile libc as will be installed for
>> users.  Ulrich wants the __foo() prototypes out of the installed headers. 
>> When compiling libc, we need the __foo() prototypes.  These are
>> contradictory goals.
>
>No, they do not inherently contradict each other.  The __ prototypes need
>not be in headers of the same name as the installed headers to be used in
>compiling libc; there are many private headers used in compiling libc that
>have private names nothing like the names of installed headers.

Hmm, so for each xyz.h we have an xyz-libc.h which provides the __
prototypes and nothing else?  Then include both.  For convenience, have
xyz-libc.h include xyz.h (probably at the very top).

If I do an interface compiler, it can keep -libc headers up to date
automatically.

>> Flick is solving a different problem I think.
>
>You are thinking too small; I did say "far in the future", didn't I?

I meant right now it's solving a different problem.

The difference I see between what Flick does now and what libc could use is
that Flick generates ABIs, but generating libc headers is about specifying
APIs.  XDR for example specifies structure-member size and alignment very
carefully but doesn't do type abstraction (I think).  Posix and C{89,9x}
want lots of type abstraction and leave structure layout to the compiler.

I have an approach in mind, which basically consists of a formal
specification per standard.  All those get glommed together and split up
into the headers.  (Per-standard, per-header spec files might be better, but
I like the idea of putting the whole standard in one place.)  In my head the
specification language is Lispish, but I should look to see if an existing
IDL can be adapted.

zw