> Date: Mon, 15 Dec 2003 10:36:39 +0000
> From: Geoff Clare <yyy@xxxxxxxxxxxxx>
>
> With Paul and Jim's adjustments, the new text would read:
>
> Otherwise, if any of the fields of the tm structure pointed to by
> timeptr contain values that are outside the normal ranges, asctime()
> behavior is undefined. If the calculated year is not in the range
> 1 through 9999 inclusive, asctime() shall either return NULL and
> set errno to EOVERFLOW, or write no more than four unspecified
> characters to the year field.
>
> It seems to me that with this new wording, EOVERFLOW is no longer the
> appropriate errno value. Perhaps EINVAL would be better.
>
> I'm also curious as to why the original aardvark singled out the
> year field for special treatment. Why should tm_min=100 produce
> undefined behaviour, but tm_year+1900=10000 be required either to
> produce an error or to write a year field with unspecified contents?
When tm_min=100, the value is out of range, and the tm struct can be
considered invalid input to asctime(). Undefined behavior for invalid
input is reasonable. OTOH, when tm_year+1900=10000, the tm structure
has values that are within range. mktime() can return such a tm structure
given the appropriate time_t. asctime() should have defined behavior
when the input is a valid tm structure.
The reasoning was to use EOVERFLOW for the error condition when the function
cannot fit the input into the output data type. This is consistent with
new AGR behavior for localtime(), gmtime(), and mktime(). Those functions
return error and set EOVERFLOW errno, because either the input time_t cannot
be represented in a struct tm (localtime() TC1, gmtime() TC1), or the
tm struct cannot be represented in the time_t (mktime() TC2). For asctime(),
using EOVERFLOW when year is longer than 4 characters, is consistent because
the date represented by the input tm structure cannot be represented in a
26-character buffer. Also allowing the behavior of writing 4 unspecified
characters lets implementations return a non-NULL pointer, if desired.
> I think that for consistency all the fields that are printed numerically
> should be treated the same. I.e. either the others should be handled
> the same way as the year is above, or all of them (including the year)
> should produce undefined behaviour. Obviously, for the fields that are
> not printed numerically (tm_mon and tm_wday), out of range values
> should always produce undefined behaviour.
>
> Jim Zepeda <yyyyyyyyyy@xxxxxxxxxxxxxxxxx> wrote, on 15 Dec 2003:
> >
> > Subject: Re: Defect in XSH asctime()
> >
> > Yes. all current calendars start at 1 and have no 0 year. But then if
> > programmers redid the calendar we would have a year 0 the months 0-B......
> >
> > So it should read "1 through 9999 inclusive"
> >
> > Jim Zepeda
> >
> > Larry Dwyer wrote:
> >
> > >Is there such a thing as year 0? I thought the calendar starts with
> > >year 1.
> > >
> > > Cheers,
> > > Larry
> > >
> > >At 11:19 PM 12/13/2003, Paul Eggert wrote:
> > >
> > >>At Fri, 12 Dec 2003 02:17:59 GMT, yyyyyyyyyyyyyyy@xxxxxxx writes:
> > >>
> > >>> (see <time.h>), and the calculated year does not exceed four
> > >>digits:
> > >>>
> > >>> page 121 line 4428 section asctime() objection
> > >>> After line 4428, add:
> > >>> Otherwise, if any of the fields of the tm structure pointed to by
> > >>> timeptr contain values that are outside the normal ranges,
> > >>asctime()
> > >>> behavior is undefined. If the calculated year exceeds four digits,
> > >>
> > >>The proposed rewording addresses only the issue where the calculated
> > >>year exceeds 9999. The specification also address the issue where the
> > >>calculated year is negative. So I would change "the calculated year
> > >>does not exceed four digits" to "the calculated year is in the range 0
> > >>through 9999 inclusive", and similarly for the other (negated)
> > >>occurrence of the wording.
|