Debian switching to EGLIBC

FWIW, I'm not fond of Ulrich's style for a lot of reasons, and this case demonstrates one of those nicely. That is to say, "sod off" is not a substitute for a proper LART. And you've earned one in that bug report, by dismissing Petr's reference to -std=c99 with "it can't affect anything".

Oddly enough, it *does* affect something. Such as the output of compiled binary (with stock glibc). Without -std=c99: out: 0x0p-15234. With it:
out: 0xa.8p+2.

And a look at strtold(3) shows where the hell had that suggestion come from:

Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

strtof(), strtold(): _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE; or cc -std=c99

Experiment with -D_ISOC99_SOURCE or -D_XOPEN_SOURCE=600 shows the same output as -std=c99. And that output looks a lot saner (10.5 * 2 * 2) than the crap produced without any of those.

I can't be arsed to dig through the macro hell in glibc headers, but that looks suspiciously like compat with some pre-c99 GNUism. Don't know, don't care and _really_ don't want to debug that shite. However, I'm quite certain that by this point you see the reasons for LART as well as I do. For the benefit of the other folks:

1) failure to RTFM
2) dismissing relevant "did you have $FOO in arguments?" with "oh, it can't matter at all"
3) failure to RTFM even after that (if nothing else, to see WTF had that question been about)
4) reporting nasal daemons as security hole, instead of (if I've parsed that bug report correctly) some crap somewhere in the clusterfsck of makefiles around glibc testsuite, either present in the original or introduced by yourself.
5) refering to the entire sad story as to evidence of security hole found by proposed patch.

Nix, you *do* know better. The above is more than enough for you to construct quite a lovely verbal clue-by-four of your own, so I'll happily leave that as an exercise for reader.