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

Re: nonnull markings in sys/cdefs.h causes trouble with gcc-3.3 ?


On Thursday 07 April 2005 10:01 pm, Roland McGrath wrote:
> If __nonnull actually has anything to do with it, that seems like the bug.
> The string.h declaration has __THROW, which in C++ is `throw ()'.  That is
> the type of the C library function.

true enough, and if you pass the example through -E it shows that gcc-3.3.x 
accepts the new prototype even when the string.h version has __THROW 
markings ...

preprocessing output that fails:
<snip>
extern char *strcasestr (__const char *__haystack, __const char *__needle)
     throw () __attribute__ ((__pure__)) __attribute__ ((__nonnull__ (1, 2)));
<snip>
char *strcasestr(const char *haystack, const char *needle);
char *strcasestr(const char *haystack, const char *needle){return 0;}
<snip>

preprocessing output that works:
<snip>
extern char *strcasestr (__const char *__haystack, __const char *__needle)
     throw () __attribute__ ((__pure__)) ;
<snip>
char *strcasestr(const char *haystack, const char *needle);
char *strcasestr(const char *haystack, const char *needle){return 0;}
<snip>

> If you don't want to write a function 
> of the same type, then you shouldn't be using the name of a function that
> is declared by the C library.

normally i'd agree, but since it seems like a certain feature which is enabled 
only for >=gcc-3.3 is triggering it, an OK workaround might be to just 
support >=gcc-3.4 since that version handles the different prototype just 
fine ...

on the other hand, why isnt it ok to define a local function even if it 
happens to use the same name as the glibc ?  since the function is only used 
locally, the external libc version wouldnt be called, and people can do what 
they want ...

> strcasestr is not a standard function, it is 
> a GNU extension.  So you won't get it if you request a standard environment
> using _POSIX_SOURCE et al, only with _GNU_SOURCE or the default condition.
> If you want to use _GNU_SOURCE, then don't try to redefine libc functions.

i'm not 100% what you mean by 'default condition' but i assume that means that 
the normal (default) behavior is to assume _GNU_SOURCE since strcasestr() is 
defined when the source code doesnt request it (in the example, there are no 
#define's requesting _GNU before including string.h)

this thread was partly to see how the glibc maintainers felt about the 
situation and to add another resource for google to turn up the next time a 
developer happens to get a related error ... after all, you guys certainly 
have no problem telling me i'm wrong :)
-mike


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