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


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

Yup, just trying to be informative.

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

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

> My solution is to transform foo() to __foo() by wrapper #defines when
> compiling libc.  This avoids the separate headers problem.

No, it does not.  There are two independent problems.  It avoids the
problem of maintaining two copies of each prototype.  It does not avoid the
problem I am most concerned about: that (for example) `#include <stdlib.h>'
in a libc source file does not process the exact same contents that it will
in a user program.  

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

Do you?  Using #define in the way you suggest is exactly what I mean by
"obscuring the name space issues".

> Flick is solving a different problem I think.

You are thinking too small; I did say "far in the future", didn't I?

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

The script and files listing the symbols in each API could be provided as
installed tools for programmers to use; I think it could be very useful.
But there is run-time cost to extra levels of version sets in the actual
shared objects you link against; we should split the version sets up only
for good technical reasons, if any should arise.


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