Fix p_secstodate overflow handling (bug 22463)

[Paul Eggert]

On 11/21/2017 05:33 AM, Joseph Myers wrote:
> RFC 4034 does not provide a specification of the
> function p_secstodate.

Although RFC 4034 does not specify the p_secstodate API, it does specify 
the string format and p_secstodate is supposed to generate that format.

I reread the RFC, and found that our patches both mishandled 
out-of-range timestamps. The RFC says that, for a timestamp greater than 
the 32-bit range, the string should be a decimal representation of the 
timestamp's low-order 32 bits. With this in mind we can simplify the fix 
since we need not worry about going past the year 2106 or about tm_year 
overflow or anything like that. We can also fix another bug, since the 
code is mishandling post-2106 timestamps now on 64-bit time_t platforms 
(just as it is mishandling post-2038 timestamps on 32-bit time_t platforms).

Attached is an (untested) patch with this simplification in mind. It 
uses your idea of a 'clock < 0' test along with a static assertion 
(though the assertion is merely that time_t is at least 32 bits wide, 
since that's all we need now) to avoid the need for complicated 
integer-overflow checking. It uses my idea to use strftime instead of 
sprintf to simplify and shorten the code and avoid having confusing 
gotos and pragmas merely to pacify GCC's false alarms. And it passes 
just an unsigned int to sprintf so that GCC doesn't spout off 
unnecessarily about format overflow.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-BZ-22463.patch
Type: text/x-patch
Size: 2608 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20171121/3a26fa02/attachment.bin>