Re: [PATCH] Define __NO_MATH_INLINES and __NO_STRING_INLINES

[Paolo Bonzini <bonzini at gnu dot org>]

> You must admit that "glibc 2.3.3 has been released" sounds a little weird
> without tarballs in the 'Release' dir and without a branch. All of this 
> *is* different, very different, from GCC.

Yes, it is.  The current scheme (correct me, no offense intended) seems 
to be like, every few months, they bump up the version number in the 
symver files, and that's it.

Note that 2.3.3 is unlikely to be ever released, because the symver 
files already point to 2.3.4.  And if it were, it would have had many 
functionality changes WRT 2.3.2: this is important a) because it *did* 
break the tree a couple of times in the past b) because it *is* even 
more different from GCC, where only bugfixes or radically new targets 
can go in after the branch is created.

> perhaps I'm being naive, I like official releases, which
> "sounds more trustworthy": f.i., can't happen that a casual patch (like
> yours for string2.h? ;) breaks things from one day to another...

Unfortunately all you can do is to trust Ulrich, Jakub and the other 
glibc hackers, and believe them when they say that glibc CVS is better 
than the last release.  It turns out to be so practically always, and a 
quick check on libc-alpha and libc-hacker will do.

As far as I'm concerned, regex (the only part of glibc on which I spent 
an interesting amount of time) is broken in all glibc 2.3 releases but 
current CVS, for multibyte locales or backreferences.

Paolo