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...
>
> [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]
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
http://www.math.clemson.edu/~mjs
More information about the fedora-list
mailing list