Email List: Xaustin-review-lX
[All Lists]

Re: Defect in XSH asctime()

To: Robbin Kawabata <yyyyyyyyyyyyyyy@xxxxxxxxxxx>
Subject: Re: Defect in XSH asctime()
From: Paul Eggert <yyyyyy@xxxxxxxxxxx>
Date: Thu, 18 Dec 2003 00:07:24 -0800
Cc: yyyyyyyyyyyyyyy@xxxxxxxxxxxxx
References: <200312171809.hBHI9sfJ208757@xxxxxx>
At Wed, 17 Dec 2003 10:09:35 -0800 (PST), Robbin Kawabata 
<yyyyyyyyyyyyyyy@xxxxxxxxxxx> writes:

> The reasoning was to use EOVERFLOW for the error condition when the
> function cannot fit the input into the output data type.

But EOVERFLOW typically denotes arithmetic overflow (e.g., an integer
can't fit into an off_t).  It's not used to denote buffer overflow.  I
could possibly see requiring EOVERFLOW if tm_year exceeds (INT_MAX -
1900), but other than that EOVERFLOW's use seems out of place here.

Also, C99 requires that asctime must behave as if sprintf were called;
see Clive D.W. Feather's email in
<http://www.opengroup.org/sophocles/show_mail.tpl?source=L&listname=austin-group-l&id=6494>.
It would be inconsistent for POSIX to define asctime_r to have an
arbitrary 26-byte limit.  If asctime_r is required to report EOVERFLOW
for years past 9999, then asctime_r cannot behave as if sprintf were
called, as sprintf doesn't have a 26-byte limit.


PS.  I see that
<http://www.opengroup.org/sophocles/show_mail.tpl?source=L&listname=austin-group-l&id=6499>
mangled my message of 16 Dec on this topic, as it dropped the first
line of my text.  This made my message hard to follow.  Here is
another copy of that proposal; I hope this copy doesn't get mangled.
Sorry about the duplication.

  At Tue, 16 Dec 2003 09:39:01 +0000, "Clive D.W. Feather" <yyyyy@xxxxxxxxx> 
writes:

  > C99 requires asctime to work whenever the specified algorithm would produce
  > defined results.

  OK, thanks; in that case POSIX should defer to C99, and the only real
  question is what asctime_r should do when it is passed a buffer longer
  than 26 bytes and when the sprintf format outputs more than 26 bytes.
  I suggest that this case be similar to asctime, so that the behavior
  is defined if the formatted output fits into the buffer passed to
  asctime_r.  So, how about this wording instead?

    The behavior of actime() and asctime_r() is undefined if tm_wday is
    not in the range 0..6, or if tm_mon is not in the range 0..11, or if
    tm_year exceeds INT_MAX - 1900, or if the formatted output,
    including the trailing null, is longer than 26 characters (for
    asctime()) or the size of _buf_ (for asctime_r()).

  If this wording is accepted, we could remove the phrase "(which shall
  contain at least 26 bytes)" in the existing DESCRIPTION for
  asctime_r(), as this phrase would become redundant.

<Prev in Thread] Current Thread [Next in Thread>