Uoti Urpala <[email protected]> writes:
> On Wed, 2012-08-01 at 21:49 +0100, Måns Rullgård wrote:
>> Uoti Urpala <[email protected]> writes:
>>
>> > On Wed, 2012-08-01 at 21:22 +0100, Måns Rullgård wrote:
>> >> >>> +int snprintf(char *buffer, size_t bufsize, const char *fmt, ...)
>> >
>> >> >>> + if ((int)bufsize <= 0) return -1;
>> >
>> >> If bufsize > INT_MAX, that cast has unspecified behaviour.
>> >
>> > No, it's implementation-defined (you're probably confusing it with
>> > arithmetic, but casts are not he same).
>>
>> I am not confused, you are.
>>
>> 3.4.4
>> unspecified behavior
>> use of an unspecified value, or other behavior where this
>> International Standard provides two or more possibilities and imposes
>> no further requirements on which is chosen in any instance
>
> OK, I guess "unspecified" does in principle also include the more
> specific class of "implementation-defined". Let's just say that your
> terminology was misleading then ("unspecified" was not a good
> description of the case, even if the word technically does apply).
There is nothing misleading about it. In this context, saying simply
unspecified is sufficient to make the point. There is no need to
further specify the kind of unspecified behaviour.
>> > BTW I wonder what perfectly standard-conforming snprintf is supposed to
>> > do with huge sizes. The size limit has type size_t, but the return value
>
>> EOVERFLOW
>
> That's what I'd expect a practical implementation to return, but is
> there something in the standard that actually makes this
> standard-conforming?
POSIX has this:
The snprintf() function shall fail if:
[EOVERFLOW]
[CX] 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}.
Plain C99 doesn't say anything that I can find at a glance.
--
Måns Rullgård
[email protected]
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
