Mail Archives: cygwin/2000/05/10/08:02:43
------------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--
- Raw text -