FW: Definition of time_t changed from signed to unsigned...
Chris Richards is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Chris Richards [mailto:cj_richards@hotmail.com] Sent: Friday, July 09, 2004 9:53 AM To: tz@lecserver.nci.nih.gov Subject: Definition of time_t changed from signed to unsigned... Hello, I am in the process of upgrading the kernel version on a platform that I work on. I noticed that the time_t definition has been changed in the newer version of the OS. It used to be a simple "long". But it is now an "unsigned long". Basically it changed from a signed to an unsigned definition. The problem is that the timezone subsystem seems to expect time_t to be signed. There are a number of functions that only work if time_t is signed. E.g. function localsub() in file localtime.c. My question is: am I just using an obsolete version of the timezone source or should I just change the time_t typedef in the OS? I quickly scanned the latest source of localtime.c and did not see any changes regarding to how time_t is declared. Thanks in advance, Chris. _________________________________________________________________ MSN Toolbar provides one-click access to Hotmail from any Web page - FREE download! http://toolbar.msn.click-url.com/go/onm00200413ave/direct/01/
Date: Mon, 12 Jul 2004 09:46:06 -0400 From: "Olson, Arthur David (NIH/NCI)" <olsona@dc37a.nci.nih.gov> Message-ID: <75DDD376F2B6B546B722398AC161106C740253@nihexchange2.nih.gov> | I am in the process of upgrading the kernel version on a platform that I | work on. I noticed that the time_t definition has been changed in the newer | version of the OS. It used to be a simple "long". But it is now an "unsigned | long". Basically it changed from a signed to an unsigned definition. Which OS is that? I made a change like that in Berkeley Unix in about 1980 (or something -- before 4.2BSD I think, maybe between 4.2 & 4.3, and way before the ado timezone library existed). It broke so much that the people at Berkeley changed it back after about 2 weeks I think. It has remained a signed type ever since... Whoever, or whatever, changed it to unsigned most likely made a big mistake. kre
From: Chris Richards [mailto:cj_richards@hotmail.com] Sent: Friday, July 09, 2004 9:53 AM
The problem is that the timezone subsystem seems to expect time_t to be signed. There are a number of functions that only work if time_t is signed. E.g. function localsub() in file localtime.c.
It's not immediately obvious to me why localsub itself assumes that time_t is signed, but I'll take your word for it. I do know that tzcode won't work well with 64-bit (signed) time_t.
My question is: am I just using an obsolete version of the timezone source or should I just change the time_t typedef in the OS?
If it's at ftp://elsie.nci.nih.gov/pub/ then it's the latest source. My advice is to keep time_t signed. Lots of applications assume that time_t is signed, and will break otherwise. POSIX doesn't require time_t to be signed (it's even allowed to be floating point!) but implementations specify an unsigned time_t at their peril.
On Fri, Jul 9, 2004 at 09:53:06AM, Chris Richards wrote:
I am in the process of upgrading the kernel version on a platform that I work on. I noticed that the time_t definition has been changed in the newer version of the OS. It used to be a simple "long". But it is now an "unsigned long".
At least as I read IEEE Std 1003.1, 2004 Edition, they just violated the Single UNIX Specification; the sys/types.h page in that spec says Additionally: ... o size_t shall be an unsigned integer type. ... o time_t and clock_t shall be integer or real-floating types. I infer from "size_t shall be an unsigned integer type" that "integer type" means "signed integer type" as opposed to "unsigned integer type"; if that inference is correct, use of "unsigned long" would violate the SUS. Perhaps the platform in question isn't trying to conform to the SUS (and perhaps earlier standards as well - they're at work, but I'm at home), but by not doing so, they're violating the expectations of at least some software, including (but not necessarily limited to) the Olson timezone code.
My question is: am I just using an obsolete version of the timezone source or should I just change the time_t typedef in the OS?
If you can, I'd change the time_t typedef in the OS. Perhaps the supplier of that platform is trying to fix the Y2.038K problem (putting the problem off another 68 years or so), but, in doing so, they run the risk of breaking some other software.
Guy Harris scripsit:
I infer from "size_t shall be an unsigned integer type" that "integer type" means "signed integer type" as opposed to "unsigned integer type"; if that inference is correct, use of "unsigned long" would violate the SUS.
No, "integer type" means "signed or unsigned integer type". -- John Cowan cowan@ccil.org www.ccil.org/~cowan www.reutershealth.com "In the sciences, we are now uniquely privileged to sit side by side with the giants on whose shoulders we stand." --Gerald Holton
Guy Harris <guy@alum.mit.edu> writes:
I infer from "size_t shall be an unsigned integer type" that "integer type" means "signed integer type" as opposed to "unsigned integer type";
This doesn't sound right to me. In POSIX and C99, "integer type" means either "char", or a signed integer type, or an unsigned integer type, or an enumeration; for the formal definition please see ISO/IEC 9899:1999 page 35 section 6.2.5 paragraph 17. This usage can also be seen in POSIX. For example, <http://www.opengroup.org/onlinepubs/000095399/basedefs/sys/types.h.html> says the following: * off_t is a signed integer type. * size_t is an unsigned integer type. * uid_t is an integer type. This illustrates three possibilities for integer types: * ((off_t) -1) must be less than zero. * ((size_t) -1) must be greater than zero. * POSIX doesn't say whether ((uid_t) -1) is less than or greater than zero, though one or the other must be true on any particular implementation. When POSIX says that time_t is an integer or real-floating type, it allows all sorts of possibilities. time_t might be any arithmetic type (including bool!) -- except that complex and imaginary numbers are excluded, thank goodness. In practice, time_t is almost always 'long int' or 'int'. Other implementations exist, but they're rare.
Guy Harris said:
o time_t and clock_t shall be integer or real-floating types. I infer from "size_t shall be an unsigned integer type" that "integer type" means "signed integer type" as opposed to "unsigned integer type";
WRONG. "signed integer type" means signed integer type. "integer type" means integer type, which can be signed, unsigned, or neither. [Read the C Standard if "neither" is unclear.]
if that inference is correct, use of "unsigned long" would violate the SUS.
It's wrong, and there is no such violation.
My question is: am I just using an obsolete version of the timezone source or should I just change the time_t typedef in the OS? If you can, I'd change the time_t typedef in the OS.
Changing an OS-supplied definition is EXTREMELY DUMB. You're risking breaking the OS interfaces. If the tz code needs a signed type, it should invent its own name for it and change all the definitions. If it needs the actual time_t type, then the code should not be making assumptions about signedness or number of bits. -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |
On Jul 19, 2004, at 1:38 AM, Clive D.W. Feather wrote:
Guy Harris said:
If you can, I'd change the time_t typedef in the OS.
Changing an OS-supplied definition is EXTREMELY DUMB. You're risking breaking the OS interfaces.
When he said "I am in the process of upgrading the kernel version on a platform that I work on.", it sounded as if he might be one of the developers *of* that platform - in which case he might be in a position to get time_t changed back to signed, if they hadn't yet shipped a release with an unsigned time_t. That's why I said "if you can".
Guy Harris said:
If you can, I'd change the time_t typedef in the OS. Changing an OS-supplied definition is EXTREMELY DUMB. You're risking breaking the OS interfaces. When he said "I am in the process of upgrading the kernel version on a platform that I work on.", it sounded as if he might be one of the developers *of* that platform
In which case it's a very different kettle of fish, I agree. I read the original thread as suggesting just changing the header file available to user code and reacted accordingly - that remains extremely dumb. Changing the OS's own definitions is, of course, completely different. If I've reacted over nothing, I apologise to all concerned. -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |
participants (6)
-
Clive D.W. Feather -
Guy Harris -
John Cowan -
Olson, Arthur David (NIH/NCI) -
Paul Eggert -
Robert Elz