Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Date: Wed, 10 May 2000 17:03:24 +0400
From: Egor Duda <deo AT logos-m DOT ru>
X-Mailer: The Bat! (v1.41)
Reply-To: Egor Duda <deo AT logos-m DOT ru>
Organization: DEO
X-Priority: 3 (Normal)
Message-ID: <1710.000510@logos-m.ru>
To: <cygwin AT sourceware DOT cygnus DOT com>
Subject: newlib's asctime() does not comply with "The Single UNIX Specification, Version 2"
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----------BE21E8F5EA731"

------------BE21E8F5EA731
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi!

Single  UNIX  Specification  V2  says  that  asctime  ()  must use the
following method to format it's output.

sprintf(result, "%.3s %.3s%3d %.2d:%.2d:%.2d %d\n",
            wday_name[timeptr->tm_wday],
            mon_name[timeptr->tm_mon],
            timeptr->tm_mday, timeptr->tm_hour,
            timeptr->tm_min, timeptr->tm_sec,
            1900 + timeptr->tm_year);

whereas current   asctime   from   anoncvs.cygnus.com   uses
"%.3s %.3s %.2d %.2d:%.2d:%.2d %d\n" string.

Easy  to  see,  that  when tm_mday < 10, newlib will pad it with
leading zero. according to standard it must pad it with space.

One  of  the  problems  arising  from  this noncompliance is described
below.

yesterday,  i've checked out (quite large) parts of anoncvs repository
to  my  machine  at work, which is running cygwin. As long as CVS uses
asctime  and friends to fill timestamp field if CVS/Entries file, some
of those entries looked like

/Makefile.in/1.2/Sun Apr 09 06:15:43 2000/-ko/

(note  the  leading  zero  in  timestap). As long as i use cvs at work
there're no problems -- cvs uses the same newlib's asctime to check if
timestamp had been changed. But then i tar.gz'ed my working copy, burn
it  on  cd and take it to my home machine, which is running linux with
glibc-2.1.1.  I've  uncompressed  working  copy  and run "cvs update".
Since  my  home  machine  has rather slow connection to internet, i've
immediately  noticed  too  much  traffic to update yesterday's working
copy.  When  i  turn on cvs's trace mode (cvs -t) i've seen that cvs's
checking   out  all  the  files  again!  Removing  leading  zeroes  in
CVS/Entries solves the problem.

I'm  not  attaching  a  (trivial)  patch  for  asctime_r.  instead i'm
attaching  small  perl  script i've used to convert all my CVS/Entries
files  to  correct format (after newlib's fixed). call it with command
like

find /src -path "*/CVS/Entries" -exec perl fix_cvs_entries.pl {} ;

Egor.            mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19
------------BE21E8F5EA731
Content-Type: application/octet-stream; name="fix_cvs_entries.pl"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="fix_cvs_entries.pl"

ICAkaW5fbmFtZSA9ICRBUkdWWzBdIDsNCiAgJHRtcF9uYW1lID0gJGluX25hbWUgLiAiLm5ldyIg
Ow0KICAkYmFrX25hbWUgPSAkaW5fbmFtZSAuICIuYmFrIiA7DQogIG9wZW4gKCBpbiwgIjwkaW5f
bmFtZSIgKSB8fCBkaWUgImNhbm5vdCBvcGVuIGlucHV0IGZpbGUgJGluX25hbWUiIDsNCiAgb3Bl
biAoIG91dCwgIj4kdG1wX25hbWUiICkgfHwgZGllICJjYW5ub3Qgb3BlbiBvdXRwdXQgZmlsZSAk
dG1wX25hbWUiIDsNCg0KICBiaW5tb2RlICggaW4gKSA7DQogIGJpbm1vZGUgKCBvdXQgKSA7DQoN
CiAgcHJpbnQgJGluX25hbWUgOw0KICANCiAgd2hpbGUgKCA8aW4+ICkNCiAgICB7DQogICAgICBp
ZiAoIGxlbmd0aCA9PSAwIG9yIHN1YnN0ciAoICRfLCAwLCAxICkgbmUgJy8nICkNCiAgICAgICAg
ew0KICAgICAgICAgIHByaW50IG91dDsNCiAgICAgICAgICBuZXh0IDsNCiAgICAgICAgfSA7DQog
ICAgICBAZW50cnkgPSBzcGxpdCAoICcvJyApIDsNCiAgICAgIGlmICggc3Vic3RyICggJGVudHJ5
WzNdLCA4LCAxICkgZXEgJzAnICkNCiAgICAgICAgew0KICAgICAgICAgIHN1YnN0ciAoICRlbnRy
eVszXSwgOCwgMSApID0gJyAnIDsNCiAgICAgICAgfQ0KICAgICAgJGxpbmUgPSBqb2luICggJy8n
LCBAZW50cnkgKSA7DQogICAgICBwcmludCBvdXQgJGxpbmUgOw0KICAgIH0NCg0KICBjbG9zZSAo
IGluICkgOw0KICBjbG9zZSAoIG91dCApIDsNCiAgDQogIEBzMSA9IHN0YXQoICRpbl9uYW1lICk7
DQogIEBzMiA9IHN0YXQoICR0bXBfbmFtZSApOw0KICBpZiAoICRzMVs3XSAhPSAkczJbN10gKQ0K
ICAgIHsNCiAgICAgIGRpZSAiZXJyb3IuIGZpbGUgc2l6ZXMgZGlmZmVyLiBjaGFuZ2VzIHdhcyBu
b3Qgc2F2ZWQiIDsNCiAgICB9DQoNCiAgcmVuYW1lICggJGluX25hbWUsICRiYWtfbmFtZSApIHx8
IGRpZSAiY2Fubm90IHJlbmFtZSAkaW5fbmFtZSB0byAkYmFrX25hbWUiIDsNCiAgcmVuYW1lICgg
JHRtcF9uYW1lLCAkaW5fbmFtZSApIHx8IGRpZSAiY2Fubm90IHJlbmFtZSAkdG1wX25hbWUgdG8g
JGluX25hbWUiIDsNCg0KICBwcmludCAiIG9rLlxuIiA7DQoNCiAgZXhpdCAwOw==

------------BE21E8F5EA731
Content-Type: text/plain; charset=us-ascii

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
------------BE21E8F5EA731--