This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: __* in installed headers
- To: Roland McGrath <roland@frob.com>
- Subject: Re: __* in installed headers
- From: Zack Weinberg <zack@rabi.phys.columbia.edu>
- Date: Mon, 17 Aug 1998 19:07:55 -0400
- cc: libc-hacker@cygnus.com
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