OT: Requesting C advice

Matthew Saltzman mjs at clemson.edu
Fri Jun 1 23:15:23 UTC 2007

On Fri, 1 Jun 2007, Mike McCarty wrote:

> Les wrote:
>> On Fri, 2007-06-01 at 07:36 -0400, Matthew Saltzman wrote:
> [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...
> 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.

Touche.  But my real (snipped) point was about representation of 
null pointers.

> [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.

It's pretty hard to implement rand() in a re-entrant way, because it has 
to maintain a static internal state.  There are a couple of string.h 
functions that maintain static internal state information as well, where 
repeated calls with the same argument string continue scanning the string 
from where the previous call left off.

>> 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.

Not all functions can be made re-entrant.

> [snip]
> Mike

 		Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu

More information about the fedora-list mailing list