Les wrote:
On Fri, 2007-06-01 at 07:36 -0400, Matthew Saltzman wrote:
[snip]
How much effort are you willing to expend to defend against potentially
buggy compilers (as opposed to undefined or implementation-defined
behaviors)? The Intel fdiv bug would seem to prove that you should NEVER
rely on arithmetic instructions to provide the correct answer. There's an
economic tradeoff between protecting yourself from all conceivable errors
and actually getting work done.
There is a difference between implementation differences and hardware
errors, which was the microsoft error. They had
a bug in their silicon compiler that caused that IIRC.
Intel != Microsoft
They used a table indexed by the first few bits of the remainder.
Part of the table did not get filled in due to a programming error.
IIRC, it was the first four bits of the remainder. Anyway, some
info is here:
http://www.cs.earlham.edu/~dusko/cs63/fdiv.html
I'd provide you with Intel's white paper URL, but my internet access
is having problems at the moment.
[snip]
NUL character value). The string terminator character is *always* written
'\0'. The machine's representation of that value is immaterial.
No, the value of the null character is specified...
[QUOTE MODE ON]
5.2.1 Character sets
....
[#2] In a character constant or string literal, members of
the execution character set shall be represented by
corresponding members of the source character set or by
escape sequences consisting of the backslash \ followed by
one or more characters. A byte with all bits set to 0,
called the null character, shall exist in the basic
execution character set; it is used to terminate a character
string.
[QUOTE MODE OFF]
[snip]
And those systems that used the first location to store the return
address are not re-entrant, without other supporting code in the
background. I think I used one of those once as well.
There's no requirement for re-entrancy in K&R or ANSI/ISO. In fact
several standard library routines are known to not be re-entrant.
Each implementation is its own. There is no fact about all
implementation of library routines.
This is true, but knowing that the base code is not reentrant due to
design constraints or due to hardware constraints makes the difference
on modern multithreaded systems, where the same executable memory can be
used for the program (if the hardware allows that).
Every conforming implementation of C must make it such that all
functions are reentrant and must support recursion. How much work
that is on any given hardware depends on how closely the hardware
corresponds to the requirements.
[snip]
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
