This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: MT-safe annotations for gcvt and related functions
- From: Florian Weimer <fweimer at redhat dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 16 Dec 2014 20:36:01 +0100
- Subject: Re: MT-safe annotations for gcvt and related functions
- Authentication-results: sourceware.org; auth=none
- References: <548ACAD9 dot 6010906 at redhat dot com> <or61db9z30 dot fsf at free dot home>
On 12/16/2014 08:25 PM, Alexandre Oliva wrote:
The comments right after the lines you quoted above state:
@c gcvt calls sprintf, that ultimately calls vfprintf, which malloc()s
@c args_value if it's too large, but gcvt never exercises this path.
which agrees with your observation, but not with the conclusion. Do you
see any actual unsafe path that disagrees with my conclusions and
annotations in the comments above, or were you just going by the general
safety remarks about sprintf et al?
I was going with the common knowledge that sprintf isn't
async-signal-safe. :-/
I see that both vfprintf and __printf_fp might use malloc as a fallback,
but the buffer sizes we're talking about will always use alloca AFAICT.
As for the locale uses, vfprintf doesn't use it in the exercised paths
AFAICT, whereas __printf_fp does access _NL_CURRENT multiple times, but
they all access the same locale object, because they all use the result
of dereferencing the pointer to the current locale a single time, as a
result of compiler optimization, and as such it doesn't mandate the
âlocaleâ annotation, although it certainly wouldn't hurt to add it.
Interesting, I wasn't aware that the rules for these annotations work
out that way. I thought all access to the global locale object were racy.
--
Florian Weimer / Red Hat Product Security