Renaming all symbols in libmp(3)

[Christoph Mallon]

David Schultz schrieb:
> On Thu, Feb 26, 2009, Christoph Mallon wrote:
>> David Schultz schrieb:
>>> As for gcc's math builtins, most of them are buggy. They fail to
>>> respect the dynamic rounding mode, fail to generate exceptions
>>> where appropriate, fail to respect FENV_ACCESS and other pragmas,
>>> etc. Also, the complex builtins use simplified formulas that don't
>>> get the right answers for complex numbers with inf/nan components.
>>> Try running some of the tests in tools/regression/lib/msun without
>>> -fno-builtin and see what happens ;-)
>> pow() is just an example.
>> The compiler may do magic with any call which has semantics defined by 
>> the C standard in a hosted environment.
> 
> Okay, so first, the world doesn't revolve around the strictest
> possible interpretation of the C standard. For example, FreeBSD

So you haven't seen enough crashes and security problems due to sloppy 
coding in the past decades, yet? I don't agree with everything the 
standard says (e.g. it tells you that it's a bad idea to call a function 
strange_quark()), but there's no reason not to avoid a simple name clash.

> has an extension such that `printf("%s", NULL)' prints "(null)"
> instead of having undefined behavior. But gcc translates this into

This *is* perfectly valid undefined behaviour.

> `puts(NULL)', which once again has undefined behavior. You can put

And this is, too. I prefer the crash variant (or the one with the demons 
flying out of the programmers nose), because I've seen quite some 
programs which showed me "(null)" where they should have printed 
something sensible and bugs (sadly) only seem to have a real chance of 
being fixed in a timely manner, when they are hard crashes. A program 
limping along with invalid data is very bad and could be a security 
problem, too - imagine a "(null)" in an sprintf()ed path or something.

> on your lawyer hat and counter that the beloved standard doesn't
> guarantee that any such thing will work, but that's a very
> contrarian attitude; the bottom line is that it's a POLA
> violation, and the extension worked just fine for many years.

It's a POLA violation in the first place, to have a function named 
pow(), which does not the "real" pow() thing.

> Second, the problems with the math builtins I cited above violate
> even a strict interpretation of the C standard.

GCC is buggy, but that's a totally different story.

> Third, this is a digression, and this is the last I'm going to say
> about it. :-)

Me, too.