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.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
