Fix p_secstodate overflow handling (bug 22463)

[Joseph Myers]

On Tue, 21 Nov 2017, Paul Eggert wrote:

> On 11/21/2017 03:35 PM, Joseph Myers wrote:
> > My reading of section 3.2 together with section 3.1.5 would be that *when
> > giving a textual representation of a value from the wire format*, it's
> > either YYYYMMDDHHmmSS for the*actual*  time (within 2**31 seconds of the
> > present time), as long as that involves a year from 0001 to 9999, or the
> > decimal value of the 32 bits from the wire.
> 
> Sorry, I'm not quite following. Surely you don't mean that p_secstodate should
> have time-dependent behavior, i.e., that it should call clock_gettime or

No.  My suggestion would be that we should say if anything it's the 
caller's responsibility to implement any such time-dependence and to call 
p_secstodate with a complete time value rather than just the low 32 bits.  
And that we should probably obsolete this interface before 2038, which is 
when such time-dependence might start to matter for the uses in glibc.  
(Any replacement would then explicitly take a full 64-bit time value on 
all platforms, possibly with a separate interface that implements the 
logic to convert a wire-format 32-bit value into a full 64-bit time value.  
But the replacement doesn't need designing now.)

(This code should of course move to using __time64_t and __gmtime64_r or 
similar once such internal interfaces exist that are explicitly 64-bit on 
32-bit platforms - generically, internal code in glibc using time_t etc. 
should move to explicitly 64-bit interfaces once available so that it 
continues to work properly on 32-bit platforms past 2038.)

-- 
Joseph S. Myers
joseph@codesourcery.com