[PATCH] correct handling of non-constant width and precision (pr 78521)

Martin Sebor msebor@gmail.com
Tue Nov 29 20:14:00 GMT 2016


On 11/29/2016 09:56 AM, Martin Sebor wrote:
> On 11/28/2016 05:42 PM, Joseph Myers wrote:
>> On Sun, 27 Nov 2016, Martin Sebor wrote:
>>
>>> Finally, the patch also tightens up the constraint on the upper bound
>>> of bounded functions like snprintf to be INT_MAX.  The functions cannot
>>> produce output in excess of INT_MAX + 1 bytes and some implementations
>>> (e.g., Solaris) fail with EINVAL when the bound is INT_MAX or more.
>>> This is the subject of PR 78520.
>>
>> Note that failing with large bounds is questionable (there is an apparent
>> conflict between ISO C, where passing a large bound seems valid, and
>> POSIX, where large bounds require errors; see
>> <http://austingroupbugs.net/view.php?id=761>; I'm not sure if any liaison
>> issue for this ever got passed to WG14).
>
> Thanks!  That's useful background.  Let me check with Nick to see
> is he (as the POSIX/WG14 liaison) plans to submit it.  I can also
> write it up for the next WG14 meeting if we or the Austin Group
> feel like WG14 should clarify or change things.

I've been looking at the original BSD sources where snprintf came
from (AFAICT).  The first implementation I could find is in Net/2
from 1988.  It returns EOF when the size after conversion to int
is less than 1.  The same code is still in 4.4BSD.

Early UNIX implementations also have the limitation that the buffer
size maintained by struct FILE is an int.  Since snprintf on these
early implementations usually uses vfprintf to do the work (with
the count being set to the snprinf bound), it can't store more than
INT_MAX bytes without overflowing the counter.

http://minnie.tuhs.org/cgi-bin/utree.pl?file=Net2/usr/src/lib/libc/stdio/snprintf.c

It looks to me like the POSIX spec is faithful to the historical
implementations and C should consider either tightening up its
constraints or make the behavior implementation-defined to allow
for more modern implementations that don't have this restriction.

Martin



More information about the Gcc-patches mailing list