This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 64-bit snprintf/vsnprintf overflow condition


> On 10/29/2010 12:03 PM, David A. Ramos wrote:
>> Hi,
>> 
>> It looks like the overflow condition in vsnprintf/snprintf is unnecessarily restrictive for 64-bit architectures.
>> 
>> from libc/stdio/snprintf.c:
>> 52  if (size > INT_MAX)
>> 53    {
>> 54      ptr->_errno = EOVERFLOW;
>> 55      return EOF;
>> 56    }
>> 
>> I believe it should use SIZE_MAX, rather than INT_MAX.
> 
On Oct 29, 2010, at 11:20 AM, Eric Blake wrote:

> It MUST be INT_MAX.  That's because the return value is int, not size_t.
> 
> Here's what POSIX has to say about it:
> 
> http://www.opengroup.org/onlinepubs/9699919799/functions/snprintf.html
> The snprintf() function shall fail if:
> 
> [EOVERFLOW]
>    [CX] [Option Start] The value of n is greater than {INT_MAX} or the
> number of bytes needed to hold the output excluding the terminating null
> is greater than {INT_MAX}. [Option End]

I'll concede that this does appear to be the POSIX-mandated behavior. It makes sense to return EOVERFLOW if the number of bytes to be written exceeds INT_MAX, but 'n' is simplify the maximum length of the buffer. If 'n' is greater than INT_MAX, it makes more sense to treat it as INT_MAX rather than immediately returning an error code. I guess my dispute is with POSIX then, not newlib.

The testcase that exposed this issue passes a large 'n', but the actual number of bytes written is very small. Nothing overflows, so EOVERFLOW is inappropriate behavior.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]