- tz - lists.iana.org

Re: problem with detzcode on machines w/64 bit longs
by Chris Torek March 12, 1995

March 12, 1995

>Gawd - Chris, really, wouldn't just [perfectly simple portable code] >work rather more easily ... Yep, but I am not embarrassed ... as I said, it is these soma pills that are doing this to me. :-) (Seriously, this `muscle relaxant' seems to let one's mind leak out the ears. They do help out with the muscle spasm, but they make it like trying to program while drunk out of one's mind...) Chris

1 0

Re: problem with detzcode on machines w/64 bit longs
by Chris Torek March 11, 1995

March 11, 1995

>However, not all operating systems have [int32_t] ... Probably a case >for #ifdef'ing the code. Hm, good point, I was thinking of BSD systems specifically. (It is these `soma' muscle relaxant pills! I swear! :-) ) If one is to resort to #ifdef's, the original suggestion of testing the top bit and OR'ing in ~0L << 32 should work, using something like: #if LONG_MAX > 2147483647 /* long > 32 bits */ if (result & (1L << 31)) result |= ~0L << 32; #endif return (result); The (long)(int32_t) method may produce better code on an Alpha, Chris

2 1

Re: problem with detzcode on machines w/64 bit longs
by Chris Torek March 11, 1995

March 11, 1995

>How about ... (result >> 31) ? (result | (~0L << 32)) : result The minimum number of bits in a `long' is 32 (LONG_MIN and LONG_MAX must be at most -2147483647 and +2147483647 respectively; the former allows for ones-complement). The result of a shift operator is defined if and only if the shift count does not equal or exceed the number of bits in the type. Thus, on a machine with 32-bit ints, `~0L << 32' is undefined. More practically, on (say) a VAX, the shift instruction only looks at the low 5 bits of the shift count, so ~0L << 32 will be ~0L => -1. Since there is now a new ugly set of `intNN_t' typedefs in <machine/types.h>, your best bet is probably: return (time_t)(int32_t)result; Chris

2 1

Re: problem with detzcode on machines w/64 bit longs
by Tom Peterson March 10, 1995

March 10, 1995

>> yeah, that should work as desired, though i forget if "0L" is an >> ansi-C-ism, and don't have a book around to check... > >Yep, it's in there. Section 3.1.3.2 of the spec I have dated 1990. >I think this has been around for a while, probably in K&R too. Just checked & it's definitely in K&R too. Appendix A section 2.4.2. - Tom

1 0

Re: problem with detzcode on machines w/64 bit longs
by Bradley White March 10, 1995

March 10, 1995

> Chris Demetriou, who maintains the NetBSD DEC Alpha port, reported a > problem in localtime.c's detzcode() function that occurs because the > value being extracted from the string in that function is not sign > extended properly. > > He says: > The problem is that if you do what the current version does, > then you can end up with numbers like 0xffffyyyy being > returned from detzcode(), i.e. no sign extension into the > upper 32 bits of the long. Because of this, among other > things, 'date' will say that it's some time in the year > 2025... > > Using the following detzcode() implementation (which unrolls the loop > and doesn't mask the first character) works, but it suffers from a > small defect in that it assumes signed characters. > > static long > detzcode(codep) > const char * const codep; > { > register long result; > > result = (codep[0] << 24) \ > | (codep[1] & 0xff) << 16 \ > | (codep[2] & 0xff) << 8 > | (codep[3] & 0xff); > return result; > } > > casting codep[0] to signed char would fix that, but would require a > ANSI compiler. How about this simple change? *** tz95b/localtime.c Sat Mar 4 11:22:26 1995 --- localtime.c Fri Mar 10 08:51:53 1995 *************** *** 186,200 **** static long detzcode(codep) const char * const codep; { register long result; register int i; ! result = 0; for (i = 0; i < 4; ++i) result = (result << 8) | (codep[i] & 0xff); return result; } static void settzname P((void)) --- 186,200 ---- static long detzcode(codep) const char * const codep; { register long result; register int i; ! result = ~0; for (i = 0; i < 4; ++i) result = (result << 8) | (codep[i] & 0xff); return result; } static void settzname P((void))

3 4

Re: problem with detzcode on machines w/64 bit longs
by Bradley White March 10, 1995

March 10, 1995

> right, but then you _always_ have the top 32 bits set. Ergh. Sorry.

1 0

problem with detzcode on machines w/64 bit longs
by J.T. Conklin March 10, 1995

March 10, 1995

Chris Demetriou, who maintains the NetBSD DEC Alpha port, reported a problem in localtime.c's detzcode() function that occurs because the value being extracted from the string in that function is not sign extended properly. He says: The problem is that if you do what the current version does, then you can end up with numbers like 0xffffyyyy being returned from detzcode(), i.e. no sign extension into the upper 32 bits of the long. Because of this, among other things, 'date' will say that it's some time in the year 2025... Using the following detzcode() implementation (which unrolls the loop and doesn't mask the first character) works, but it suffers from a small defect in that it assumes signed characters. static long detzcode(codep) const char * const codep; { register long result; result = (codep[0] << 24) \ | (codep[1] & 0xff) << 16 \ | (codep[2] & 0xff) << 8 | (codep[3] & 0xff); return result; } casting codep[0] to signed char would fix that, but would require a ANSI compiler. --jtc

1 0

patch to newctime.3 (relative to tzcode95b)
by J.T. Conklin March 10, 1995

March 10, 1995

The enclosed patch adds some const qualifiers to function arguments, and changes long's to time_t's as appropriate. --jtc diff -c -r1.3 -r1.4 *** newctime.3 1995/03/10 00:05:54 1.3 --- newctime.3 1995/03/10 00:09:36 1.4 *************** *** 11,17 **** .B #include <sys/types.h> .PP .B char *ctime(clock) ! .B time_t *clock; .PP .B double difftime(time1, time0) .B time_t time1; --- 11,17 ---- .B #include <sys/types.h> .PP .B char *ctime(clock) ! .B const time_t *clock; .PP .B double difftime(time1, time0) .B time_t time1; *************** *** 20,32 **** .B #include <time.h> .PP .B char *asctime(tm) ! .B struct tm *tm; .PP .B struct tm *localtime(clock) ! .B long *clock; .PP .B struct tm *gmtime(clock) ! .B long *clock; .PP .B time_t mktime(tm) .B struct tm *tm; --- 20,32 ---- .B #include <time.h> .PP .B char *asctime(tm) ! .B const struct tm *tm; .PP .B struct tm *localtime(clock) ! .B const time_t *clock; .PP .B struct tm *gmtime(clock) ! .B const time_t *clock; .PP .B time_t mktime(tm) .B struct tm *tm;

1 0

Re:unistd.h
by ado Feb. 23, 1995

Feb. 23, 1995

After receiving the message... > I ftped the tz*95 data from elsie.nci.nih.gov. However, all the little > utilities #include the file 'private.h', which in turn #includes > a file called 'unistd.h', which unfortunately is not available > on my system. ...I followed up asking for details and learned that... > What I'm using is a win311/dos system. My c compiler is > microsoft's c/c++ ver. 7. If anyone knows where F_OK and R_OK (manifest constants needed when calling "access") can be found when using the above compiler, I'd appreciate hearing from you by electronic mail. Note that it isn't any of... #include "sys/types.h" /* for time_t */ #include "stdio.h" #include "ctype.h" #include "errno.h" #include "string.h" #include "limits.h" /* for CHAR_BIT */ #include "time.h" #include "stdlib.h" #include "unistd.h" /* for F_OK and R_OK */ --ado

1 0

unistd.h
by peternm＠oslonett.no Feb. 21, 1995

Feb. 21, 1995

Following Paul Eggert's (eggert(a)twinsun.com) advice, I ftped the tz*95 data from elsie.nci.nih.gov. However, all the little utilities #include the file 'private.h', which in turn #includes a file called 'unistd.h', which unfortunately is not available on my system. Is this file crucial to any of the functions in the package, or can I safely delete the reference without ill side effects? All the best, Peter ============================================================ Peter N. M. Hansteen peternm(a)oslonett.no Datadokumentasjon A/S, Bredsgaarden 2, N-5003 Bergen, Norway Tel: +47 55 32 08 02 Fax: +47 55 32 14 95

1 0