OT: Requesting C advice

[Mike McCarty]

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!