Re: Miscompilation of remainder expressions
For sure a/b is undefined In C, it is. In assembler it is perfectly well defined, i.e., it traps. But how is the trap handler supposed to know the source of a given instruction? M.
Re: Relying on precise integer calculation with double
gcc really, really ought to specify more precisely what floating point
semantics one can depend on.
Bug 323, paraphrased, says floating point comparisons return random
numbers. Ok, that's pumping it a bit, but consider the following
qsort comparison function right out of KR 2nd Edition page 121:
int numcmp(char *s1, char *s2)
{
double v1, v2;
v1 = atof (s1);
v2 = atof (s2);
if (v1 v2)
return -1;
else if (v1 v2)
return 1;
else
return 0;
}
[Ignore NaNs, strings that don't yield numbers, missing consts, and
the silliness of calling atof inside this function.]
Bug 323 says that the two comparisons can return results that are
inconsistent from a mathematical point of view. (And, in principle,
that even with identical arguments one could get different results
for calls.) In either case, qsort with such a function is undefined
behaviour according to C99. And in practice, bad things do happen
if the comparison function returns inconsistent results, for example
on Solaris
It doesn't look like the C99 macros isless, etc., can resolve the
issue. One would need a single call producing the final ordering
result, or an int from which it could be derived.
So there. One cannot sort floating point values with qsort under
gcc if Bug 323 is the final word on semantics. In practice it
works just fine.
Morten
Re: funny problem with g++
This is a joke, you are kidding, right ? No, we're not kidding. RTFM: Section, 5.12 Arrays of Length Zero He is kind of right, though. Outside struct (or perhaps union), zero-sized arrays make little sense and could be rejected. Or else I am missing something too. M.
Re: Pointers in comparison expressions
Relational tests between pointers is only allowed by the ISO C standard if the two pointers point into the same array, or if a pointer points to exactly one byte beyond the array. There actually is a way to compare arbitrary data pointers within the C standards: you send the pointers through a printf- type function using %p and strcmp the results. That'll give you some kind of ordering, though not necessarily the obvious one. (No, I am not serously suggesting that anyone in their right mind you actually do so. Why does this keyboard have a smiley key?) Note, btw., that such use of %p also rules out using a garbage collector for C and C++. It simply cannot work if some of your pointers have been sent off by email to the other end of the world. At the very least you would have to consider any pointer that made it through %p to be live forever. Morten
Re: signed is undefined and has been since 1992 (in GCC)
In particular, a very large number of C and C++ programs are written with the assumptions: - signed and unsigned types are modulo, except in loop induction variables where it's bad taste Well, as demonstrated by INT_MIN/-1, gcc has NEVER fulfilled such assumptions on i86 and, quite likely, neither has or will any other compiler. The runtime penalty would be too big and hurt performance numbers. What I believe you can find examples of is that the more restricted claim of addition and perhaps subtraction of signed numbers is modulo is being assumed. That's cheap since (for 2-complement) signed addition is the same operation as unsigned addition. Morten
Re: Do C++ signed types have modulo semantics?
| signed types are undefined on overflow. [5/5] and [3.9.1/2,3] But a compiler could define them to be modulo -- that is the whole point. The paragraph does not say they don't modulo. True, but you are going to have to deal with the run-time version of (int)0x8000 / -1 which is unpleasant in the sense that Intel processors will trap and not do anything modulo-like. Morten
Re: Sine and Cosine Accuracy
Yes, but within the defined mathematical ranges for sine and cosine -- [0, 2 * PI) -- the processor intrinsics are quite accurate. If you were to look up a serious math book like AbramowitzStegun1965 you would see a definition like sin z = ((exp(iz)-exp(-iz))/2i [4.3.1] for all complex numbers, thus in particular valid for z=x+0i for all real x. If you wanted to stick to reals only, a serious math text would probably use the series expansion around zero [4.3.65] And there is the answer to your question: if you just think of sin as something with angles and triangles, then sin(2^90) makes very little sense. But sin occurs other places where there are no triangles in sight. For example: Gamma(z)Gamma(1-z) = pi/sin(z pi) [6.1.17] or in series expansions of the cdf for the Student t distribution [26.7.4] Morten
