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


> 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.

> 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.  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.

> 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.

> 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/).

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.



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