This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: __* in installed headers


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]