Hello,

In a different forum, someone claimed that atoi is not thread-safe,
even if the implementation defines _POSIX_C_SOURCE to 200809L.

I'm 90% sure an implementation cannot be POSIX-compliant unless
atoi is thread-safe, and I think this requirement has existed
since POSIX.1c was released in 1995. Am I mistaken?

"Thread-safety and POSIX.1" (1) states:
> POSIX.1c takes three actions in the pursuit of reentrancy. First,
> POSIX.1c imposes reentrancy as a general rule: all functions, unless
> explicitly singled out as exceptions to the rule, must be implemented
> in a way that preserves reentrancy. Second, POSIX.1c redefines errno,
> as described below in . Third, for those functions whose interface
> specifications preclude reentrancy, POSIX.1c defines alternative
> "reentrant" versions as follows: [snip]

(1) http://www.unix.org/whitepapers/reentrant.html

POSIX:2004 (2) states:
> All functions defined by this volume of IEEE Std 1003.1-2001 [sic]
> shall be thread-safe, except that the following functions need not
> be thread-safe. [snip list which includes neither atoi nor strtol]
> Implementations shall provide internal synchronization as necessary
> in order to satisfy this requirement.

(2) http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html

POSIX:2008 (3) states:
> All functions defined by this volume of POSIX.1-2008 shall be
> thread-safe, except that the following functions need not be
> thread-safe. [snip list]
> Implementations shall provide internal synchronization as necessary
> in order to satisfy this requirement.
> Since multi-threaded applications are not allowed to use the environ
> variable to access or modify any environment variable while any other
> thread is concurrently modifying any environment variable, any
> function dependent on any environment variable is not thread-safe if
> another thread is modifying the environment; see XSH exec.

(3) http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_01

The description for atoi
http://pubs.opengroup.org/onlinepubs/9699919799/functions/atoi.html
states nothing about thread-safety, and mentions
> The call atoi(str) shall be equivalent to:
> (int) strtol(str, (char **)NULL, 10)

The description for strtol
http://pubs.opengroup.org/onlinepubs/9699919799/functions/strtol.html
mentions errno (that's taken care of), and isspace.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/isspace.html

I think Apple (or Darwin, or FreeBSD) considers isspace is not thread-safe
because a thread may change the locale while another thread is calling atoi.
But since isspace is not in the list of not thread-safe functions, then it
must be thread-safe for a POSIX implementation.

Matters may be made more confusing by the fact that C1X defined isspace_l?

Comments? Thoughts?

Noob wrote:

> I think Apple (or Darwin, or FreeBSD) considers isspace is not thread-safe
> because a thread may change the locale while another thread is calling atoi.
> But since isspace is not in the list of not thread-safe functions, then it
> must be thread-safe for a POSIX implementation.
> 
> Matters may be made more confusing by the fact that C1X defined isspace_l?

Additional notes for my own reference.

http://stackoverflow.com/questions/4631310/why-does-osx-document-atoi-atof-as-not-being-threadsafe
(which concludes that atoi *must* be thread-safe on POSIX
platforms because POSIX doesn't say otherwise)

setlocale - set program locale
http://pubs.opengroup.org/onlinepubs/9699919799/functions/setlocale.html
> The locale state is common to all threads within a process.

7. Locale
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html

Noob wrote:

> In a different forum, someone claimed that atoi is not thread-safe,
> even if the implementation defines _POSIX_C_SOURCE to 200809L.
> 
> I'm 90% sure an implementation cannot be POSIX-compliant unless
> atoi is thread-safe, and I think this requirement has existed
> since POSIX.1c was released in 1995. Am I mistaken?
> 
> "Thread-safety and POSIX.1" (1) states:
>> POSIX.1c takes three actions in the pursuit of reentrancy. First,
>> POSIX.1c imposes reentrancy as a general rule: all functions, unless
>> explicitly singled out as exceptions to the rule, must be implemented
>> in a way that preserves reentrancy. Second, POSIX.1c redefines errno,
>> as described below in . Third, for those functions whose interface
>> specifications preclude reentrancy, POSIX.1c defines alternative
>> "reentrant" versions as follows: [snip]
> 
> (1) http://www.unix.org/whitepapers/reentrant.html
> 
> POSIX:2004 (2) states:
>> All functions defined by this volume of IEEE Std 1003.1-2001 [sic]
>> shall be thread-safe, except that the following functions need not
>> be thread-safe. [snip list which includes neither atoi nor strtol]
>> Implementations shall provide internal synchronization as necessary
>> in order to satisfy this requirement.
> 
> (2) http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html
> 
> POSIX:2008 (3) states:
>> All functions defined by this volume of POSIX.1-2008 shall be
>> thread-safe, except that the following functions need not be
>> thread-safe. [snip list]
>> Implementations shall provide internal synchronization as necessary
>> in order to satisfy this requirement.
>> Since multi-threaded applications are not allowed to use the environ
>> variable to access or modify any environment variable while any other
>> thread is concurrently modifying any environment variable, any
>> function dependent on any environment variable is not thread-safe if
>> another thread is modifying the environment; see XSH exec.
> 
> (3) http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_01
> 
> The description for atoi
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/atoi.html
> states nothing about thread-safety, and mentions
>> The call atoi(str) shall be equivalent to:
>> (int) strtol(str, (char **)NULL, 10)
> 
> The description for strtol
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/strtol.html
> mentions errno (that's taken care of), and isspace.
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/isspace.html
> 
> I think Apple (or Darwin, or FreeBSD) considers isspace is not thread-safe
> because a thread may change the locale while another thread is calling atoi.
> But since isspace is not in the list of not thread-safe functions, then it
> must be thread-safe for a POSIX implementation.
> 
> Matters may be made more confusing by the fact that C1X defined isspace_l?

My conclusion is: "atoi is thread-safe [on POSIX platforms]
because POSIX says so."

I'd like to hear dissenting opinions.

Regards.

Noob wrote:

> In a different forum, someone claimed that atoi is not thread-safe,
> even if the implementation defines _POSIX_C_SOURCE to 200809L.
> 
> I'm 90% sure an implementation cannot be POSIX-compliant unless
> atoi is thread-safe, and I think this requirement has existed
> since POSIX.1c was released in 1995. Am I mistaken?
> 
> "Thread-safety and POSIX.1" (1) states:
>> POSIX.1c takes three actions in the pursuit of reentrancy. First,
>> POSIX.1c imposes reentrancy as a general rule: all functions, unless
>> explicitly singled out as exceptions to the rule, must be implemented
>> in a way that preserves reentrancy. Second, POSIX.1c redefines errno,
>> as described below in . Third, for those functions whose interface
>> specifications preclude reentrancy, POSIX.1c defines alternative
>> "reentrant" versions as follows: [snip]
> 
> (1) http://www.unix.org/whitepapers/reentrant.html
> 
> POSIX:2004 (2) states:
>> All functions defined by this volume of IEEE Std 1003.1-2001 [sic]
>> shall be thread-safe, except that the following functions need not
>> be thread-safe. [snip list which includes neither atoi nor strtol]
>> Implementations shall provide internal synchronization as necessary
>> in order to satisfy this requirement.
> 
> (2) http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html
> 
> POSIX:2008 (3) states:
>> All functions defined by this volume of POSIX.1-2008 shall be
>> thread-safe, except that the following functions need not be
>> thread-safe. [snip list]
>> Implementations shall provide internal synchronization as necessary
>> in order to satisfy this requirement.
>> Since multi-threaded applications are not allowed to use the environ
>> variable to access or modify any environment variable while any other
>> thread is concurrently modifying any environment variable, any
>> function dependent on any environment variable is not thread-safe if
>> another thread is modifying the environment; see XSH exec.
> 
> (3) http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_01
> 
> The description for atoi
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/atoi.html
> states nothing about thread-safety, and mentions
>> The call atoi(str) shall be equivalent to:
>> (int) strtol(str, (char **)NULL, 10)
> 
> The description for strtol
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/strtol.html
> mentions errno (that's taken care of), and isspace.
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/isspace.html
> 
> I think Apple (or Darwin, or FreeBSD) considers isspace is not thread-safe
> because a thread may change the locale while another thread is calling atoi.
> But since isspace is not in the list of not thread-safe functions, then it
> must be thread-safe for a POSIX implementation.
> 
> Matters may be made more confusing by the fact that C1X defined isspace_l?

Anyone?

Noob wrote:

>> In a different forum, someone claimed that atoi is not thread-safe,
>> even if the implementation defines _POSIX_C_SOURCE to 200809L.
>> 
>> I'm 90% sure an implementation cannot be POSIX-compliant unless
>> atoi is thread-safe, and I think this requirement has existed
>> since POSIX.1c was released in 1995. Am I mistaken?

No, you're completely correct.

-- 
Geoff Clare <netnews@gclare.org.uk>