This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: [RFC]setlocale() race condition
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: "Sharyathi Nagesh" <sharyath at in dot ibm dot com>
- Cc: libc-help at sourceware dot org, suzukikp at in dot ibm dot com, sripathi at in dot ibm dot com
- Date: Thu, 12 Jun 2008 10:00:09 -0400
- Subject: Re: [RFC]setlocale() race condition
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=QxlEihHYAYdxH+n8Tn4qe/wAgtAs4btDN21dBFBUSC0=; b=nLd6RBf0QLT7DPxUEkJGThHre3pvs3sS50tgRVrtTNyAdH8/DoFv8AACKviKnHDlej PGq7Y8FqZpsDZlEKDF9WC104TkEhuxyx0KctT42yHX60cjMBzLDQMGDqM1orRTQmXe2y N6ErlytT4mAJJg+MX6RMQHkM5wjt6dmTbkN2o=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=tHKoF1J2c2Dloi3NpYyEBoXQF2eZ3uPQiyeQzI+ikA1HYlzPsiS1Y6lVA/heNELSWu dpBffs6IedHmRtFyiht4gfNqyTF5wyJS3pnXTe78nPOimNKh4puk9/EAP6TzqoO5Bbt0 KUpaBDeOP2Q8ckS8/yGnRLSfo8n2eeAFK7SLE=
- References: <48509BC2.8040102@in.ibm.com>
On Wed, Jun 11, 2008 at 11:45 PM, Sharyathi Nagesh <sharyath@in.ibm.com> wrote:
> Since the man page of setlocale() doesn't talk any thing about the
> call `not being re-entrant` I assume setlocale() to be re-entrant
setlocale() is not on the POSIX.1 list of async-signal safe functions
and is therefore not re-entrant or thread-safe.
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html#tag_02_04
Please note that re-entrancy and thread safety are related but
different terms. A re-entrant function need not be thread safe,
imagine two threads passing in the *same* structure to a re-entrant
function, without synchronization access to the structure is
unpredictable. A non-re-entrant function may be thread safe if access
to the global state is synchronized.
Are you suggesting that setlocale() although not re-entrant, should be
made thread safe according to the standard?
Cheers,
Carlos.