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: Fri, 14 Aug 1998 17:29:06 -0400
- cc: libc-hacker@cygnus.com
On Fri, 14 Aug 1998 15:33:52 -0400, Roland McGrath wrote:
>> One issue - which might just be a maintenance headache but I think it may be
>> worse than that - is keeping track, inside libc, of which functions are
>> addressed as foobar() and which as __foobar(). I don't have the code in
>> front of me but I dimly remember that the sockets code was about half and
>> half.
>
>Most sections of library have nonuniform __-name usage. For the most part,
>they have just been added as needed; that is, when some standard function
>foo needs to call some function bar that's not allowed by foo's standard,
>then we add __bar.
Ok. This may or may not be the right thing but that's a separate issue.
>> 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?
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.
My solution is to transform foo() to __foo() by wrapper #defines when
compiling libc. This avoids the separate headers problem. It raises a
problem with the compilation of auxiliary programs, which can be avoided by
suitable #ifdefs. There may be other issues with this approach but they
would be present in Uli's approach also. Or so it seems to me.
>For libc
>maintenance, I think obscuring the name space issues in the source will end
>up making life harder, not easier. There aren't that many rules to worry
>about; we're better off with hackers keeping the reality clear in their heads.
I agree here.
>> Fixing the libc vs. aux programs issue can be done simply: adjust the CFLAGS
>> for aux programs so they don't get libc-symbols.h, and have the wrapper
>> #defines predicated on _LIBC or analogous preprocessor symbol. Aux programs
>> probably shouldn't have libc-symbols.h anyway.
>
>I don't know what issue you mean to address by this. I don't really care
>if the auxiliary programs use libc-internal stuff; if they don't, they
>probably ought to be in a separate distribution anyway. If it's useful for
>them to do so, then I don't see any need to worry about compiling those
>programs outside the libc source tree.
Most of the aux programs could (I think) be in a separate distribution
without being damaged. For example, the db2 stuff is only in libc because
NSS has a db2 back end.
The problem that arises with my wrapper-#defines approach is that aux
programs will try to use internal symbols if we keep compiling them as if
they were part of the library.
>> As a related issue, I was thinking about a interface compiler, like MiG but
>> much simpler, for libc. Its primary function would be to make cleaning the
>> namespace easier: you'd tag prototypes as C89, C9x, POSIX, etc. and it would
>> supply appropriate #ifdefs. It could also automate keeping public and
>> private prototypes in sync.
>
>Well, that would be nifty. You might consider hacking based on gcc's
>protoize stuff; there is already code there to operate on a C syntax tree
>and to print C syntax decls, it wouldn't be hard to whip something up along
>those lines. You've also given me the idea to suggest this sort of thing
>as something to consider to the people hacking a flexible IDL compiler in
>my research group (this will be far in the future; see about the project at
>http://www.cs.utah.edu/projects/flux/flick/).
Flick is solving a different problem I think. It generates IPC/RPC stubs.
What we could use is a program to take formal specifications of N interface
standards, merge them, and spit out C headers. (Hm, maybe diff --ifdef
could be scripted into doing the job.) Starting with protoize could work.
>Another thing that occurred to me before your suggestion, that could
>probably be done with some script hackery and ld magic: it would be useful
>to have a frob that used ld version scripts to define a version set (or
>whatever those things are called, like "GLIBC_2.1" et al) for each
>standardized API (ANSI C, ISO C, POSIX.1, Unix98, etc) using the
>dependencies to indicate what is allowed to call what (i.e. POSIX can call
>ANSI C; Unix98 can call POSIX; etc), and do some mock-up ld runs on
>libc.a and libc_pic.a and dick around with binutils magic to spit out red
>flags for every non-__ external symbol that is defined in an object in
>version-set FOO but which symbols is not in FOO.
You might even be able to put those tags into the production library, so
that pedants could do link-time checks for nonstandard function usage in
their programs. (I'm not sure how useful that would be.)
zw