[patch] Fix BZ 18985 out of bounds access in strftime

[Martin Sebor]

On 09/20/2015 12:38 AM, Paul Eggert wrote:
> Paul Pluzhnikov wrote:
>> +  /* Do range checks first.  BZ #18985  */
>> +  if (tp->tm_sec < 0 || tp->tm_sec > 60
>> +      || tp->tm_min < 0 || tp->tm_min > 59
>> +      || tp->tm_hour < 0 || tp->tm_hour > 23
>> +      || tp->tm_mday < 0 || tp->tm_mday > 31
>> +      || tp->tm_mon < 0 || tp->tm_mon > 11
>> +      || tp->tm_wday < 0 || tp->tm_wday > 6
>> +      || tp->tm_yday < 0 || tp->tm_yday > 365
>> +      || tp->tm_isdst < 0 || tp->tm_isdst > 1)
>> +    {
>> +      __set_errno (EINVAL);
>> +      return 0;
>> +    }
>
> That doesn't look right.  If the values are out of range, C11 and POSIX
> say strftime is supposed to store an unspecified string, not return 0.
>
> tzcode strftime stores "?" for out-of-range tm_mon and tm_wday, and
> looks only at the sign of tm_isdst; this conforms to the standard.
> FreeBSD strftime is similar.  glibc could do the same; that should be
> both easy and compatible.

I tend to agree, although while I suspect it wasn't the intent,
an argument could be made that the patch is strictly conforming
on the basis that storing the unspecified characters would produce
a string that's longer than maxsize characters, in which case the
function is supposed to return 0.

Martin