This is the mail archive of the libc-alpha@sourceware.org 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]
Other format: [Raw text]

Re: [PATCH] Don't check ABI for _nl_default_dirname


> Why shouldn't someone, the implementation in particular, want to
> rely on that array being the correct size? I don't see it as a bug,
> and you haven't provided a detailed rationale for rejecting parts
> of the ABI that vary by configuration options.

_nl_default_dirname is a char [] array.

The only change with different prefix is the symbol size of the
_nl_default_dirname, but a C program cannot even know the symbol size
because size is not part of a C symbol.

In C++ it could happen because the symbol size may be encoded into the
name there. But glibc is not C++ and _nl_default_dirname is not mangled,
so this doesn't apply.

The only way in C to know the size of a extern symbol is to hardcode 
the size in a header declaration. But:
- there is no header for _nl_default_dirname
- even if there was the size in the header would not change because
the size is already compiled into the program

So it cannot find the size at link time.

The awk script can only find it because it uses nm and computes the 
offset to the next symbol. But a program linking to the library clearly
cannot do that.

The only thing a program could do is to run strlen() on it and bail out if the 
length is different. But that doesn't make any sense, why should it 
do that? The only point of having such a variable is that it may have
different contents, otherwise you could just have a #define.

So in summary the symbol length of this symbol is not part of the ABI
and it doesn't make any sense to check it.

-Andi


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