(OT, perhaps) Y2038 problem in UNIX ...
William Pentney
So far as I know, this staple of UNIX has not been fixed in any way. (If
it has been, I'm about to make a fool of myself; feel free to set me
straight.) When will this be dealt with?
Some of you may laugh and say that I'm thinking just a bit too far
ahead. But I'm very serious. It would be far better to resolve this
problem now then to put it off for years. The Y2K problem happened
because of the inability of most corporations to think in the long term.
(Well, to be accurate, it was initially spawned out of a need to save
memory, but its resolution is coming far too late.) I would hope that we
would not be so monopolized by short-term considerations. This problem
should be dealt with in Linux (or GNU/Linux, if you prefer). If nothing
else, we can brag about the Linux "Year 64K problem" or whatever upon
its resolution.
- Bill
Christopher B. Browne
The *right* thing is to do it in the *proper* timing, with proper
reflection, rather than rushing into a bad solution that will just make
the perpetrators be considered "virtually criminal."
In particular, there is no reason to rush off without thinking simply
because there are a "lot of zeroes" coming up this year, when the
equivalent problem is still about 38 years away. The people that
didn't think when designing data structures for PC-based software
have a little less than 7 months left, and those that didn't think
about the issue for long enough are liable to get bitten with horrid
problems on March 1, 2000. Just because such folk are assortedly
stocking up "survivalist shelters" and announcing the imminent demise
of the world does not mean that the UNIX community should join them
in the stupidity.
The *correct* way to resolve the issue has to involve at least
four components:
a) Suitable changes to the C Language to support the "greater than
32 bit values" that are necessary to the purpose.
b) Suitable changes to the C Standard Library that *use* those
values.
c) Backwards compatibility handling for LIBC so that the system
can migrate from old date format to new.
d) Suitable redesign of filesystems so that they will support
the new format.
A proper solution must affect all four of these things simultaneously.
If you want to come up with a proposal in this regard, then I suggest
you contact either the ISO or ANSI C committees as, since they are the
legal body that has responsibility for a) and b), must be convinced
of the merits of your solution.
And be aware that if you don't know how to "hack" on filesystems,
it may be wiser not to bother playing the game.
In any case, I'm quite willing to see the process for this migration
being defined over the next few years. Note that as 64 bit processors
increase in popularity, the use of a 64 bit field becomes increasingly
natural, and as code is made 64-bit clean, the problem may be very
naturally resolved without there being any need to resort to panic
at the thought that we might not get it fixed before December of this
year...
If you *really* want to be paranoid, and have a "field overflow"
problem to cause problems, consider how rapidly area codes are
proliferating in the North American telecommunications market.
What with restrictions on what digits may be used in some positions,
the permissible number of distinct numbers is closer than 1 billion
than it is to 10 billion. What with pagers, ISPs, cell phones, fax
machines, business lines, and so forth, the "name space" is running
out...
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/linuxy2k.html>
cbbr...@hex.net - "What have you contributed to free software today?..."
Peter Seebach
Christopher B. Browne <cbbr...@hex.net> wrote:
>The *correct* way to resolve the issue has to involve at least
>four components:
>a) Suitable changes to the C Language to support the "greater than
>32 bit values" that are necessary to the purpose.
C9X: int64_t. (There's also a 'long long', but this is cruft.)
>b) Suitable changes to the C Standard Library that *use* those
>values.
Already done - but not necessarily using them for time_t.
>c) Backwards compatibility handling for LIBC so that the system
>can migrate from old date format to new.
>d) Suitable redesign of filesystems so that they will support
>the new format.
Unfortunately, it looks like the existing practice camp may force some systems
to use 'time64_t' or some other monstrosity, because too much existing data
uses the old format.
>A proper solution must affect all four of these things simultaneously.
>If you want to come up with a proposal in this regard, then I suggest
>you contact either the ISO or ANSI C committees as, since they are the
>legal body that has responsibility for a) and b), must be convinced
>of the merits of your solution.
The question has been looked at, but you see, we're done already. time_t
can be as large as you want it to be. You'll never see us telling you it
isn't a double or a long long or whatever you need.
>In any case, I'm quite willing to see the process for this migration
>being defined over the next few years. Note that as 64 bit processors
>increase in popularity, the use of a 64 bit field becomes increasingly
>natural, and as code is made 64-bit clean, the problem may be very
>naturally resolved without there being any need to resort to panic
>at the thought that we might not get it fixed before December of this
>year...
There's actually a practical reason to care now: Customers who got bitten
by Y2K are fussing about *ANY* date limitations.
>If you *really* want to be paranoid, and have a "field overflow"
>problem to cause problems, consider how rapidly area codes are
>proliferating in the North American telecommunications market.
>What with restrictions on what digits may be used in some positions,
>the permissible number of distinct numbers is closer than 1 billion
>than it is to 10 billion. What with pagers, ISPs, cell phones, fax
>machines, business lines, and so forth, the "name space" is running
>out...
It's okay; in the future, we'll all use this incredible speed-dial technique
someone invented. It stores 10,000,000,000 or so distinct numbers, each
accessible through a unique 10-digit sequence. It can be implemented without
using additional memory on the phone!
-s
--
Copyright 1999, All rights reserved. Peter Seebach / se...@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Will work for interesting hardware. http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
Geoffrey KEATING
> On Fri, 04 Jun 1999 03:47:08 GMT, William Pentney <wmpe...@adelphia.net> posted:
> >A question about UNIX/Linux re: the year 2038 problem ...
> The *correct* way to resolve the issue has to involve at least
> four components:
> a) Suitable changes to the C Language to support the "greater than
> 32 bit values" that are necessary to the purpose.
> b) Suitable changes to the C Standard Library that *use* those
> values.
> c) Backwards compatibility handling for LIBC so that the system
> can migrate from old date format to new.
> d) Suitable redesign of filesystems so that they will support
> the new format.
>
> A proper solution must affect all four of these things simultaneously.
> If you want to come up with a proposal in this regard, then I suggest
> you contact either the ISO or ANSI C committees as, since they are the
> legal body that has responsibility for a) and b), must be convinced
> of the merits of your solution.
Happily, (a) is in progress (the C language will soon _require_
at-least-64-bit integers, where before it only permitted them), (b)
depends on (a) and (c) but is otherwise no trouble, glibc has the
handling required to do (c) now, and that leaves about 33 years to do
(d).
Why do you want to do them all together? I'd expect that doing one at
a time is less likely to cause pain.
--
Geoff Keating <Geoff....@anu.edu.au>
David Kastrup
> The *correct* way to resolve the issue has to involve at least
> four components:
> a) Suitable changes to the C Language to support the "greater than
> 32 bit values" that are necessary to the purpose.
> b) Suitable changes to the C Standard Library that *use* those
> values.
> c) Backwards compatibility handling for LIBC so that the system
> can migrate from old date format to new.
> d) Suitable redesign of filesystems so that they will support
> the new format.
I am afraid you are in confusion here. What you write above are the
requirements that have to be met in order to have operating systems
work at all in 2038 and beyond. But the main Y2K problem costs do not
stem from operating systems, but applications.
> In any case, I'm quite willing to see the process for this migration
> being defined over the next few years. Note that as 64 bit processors
> increase in popularity, the use of a 64 bit field becomes increasingly
> natural, and as code is made 64-bit clean, the problem may be very
> naturally resolved without there being any need to resort to panic
> at the thought that we might not get it fixed before December of this
> year...
Oh, sure. Like the Y2K-problem went away when 8-Bit processors were
replaced by 16- and 32-Bit processors.
This is wishful thinking that got us into the Y2K problem in the first
place. Thinking "these systems will be obsoleted pretty soon, and
somehow or other all calculations and programs and data file formats
will magically convert themselves to work with newer systems at that
time" are *exactly* the reasons for the massive Y2K problems.
--
David Kastrup Phone: +49-234-700-5570
Email: d...@neuroinformatik.ruhr-uni-bochum.de Fax: +49-234-709-4209
Institut für Neuroinformatik, Universitätsstr. 150, 44780 Bochum, Germany
Hrvoje Niksic
> problem now then to put it off for years. The Y2K problem happened
> because of the inability of most corporations to think in the long
> term. (Well, to be accurate, it was initially spawned out of a need
> to save memory,
Ha ha ha! Saving memory, indeed.
Jan Vroonhof
> This is wishful thinking that got us into the Y2K problem in the first
> place. Thinking "these systems will be obsoleted pretty soon, and
> somehow or other all calculations and programs and data file formats
> will magically convert themselves to work with newer systems at that
> time" are *exactly* the reasons for the massive Y2K problems.
However there some factors that would one lead to expect that those
problems should be less grave
1. Seconds since 19700101 are not used in user interfaces.
2. There is no change in the actual representation of the data. It is
only the size of the field that changes, i.e. no 02 = 1902 or 2002
problems.
3. Compilers can catch 64bit types being stuffed into 32bit fields.
Jan
Barry Margolin
Jonathan Stott <jstott...@poly.phys.cwru.edu> wrote:
>In article <slrn7lekra....@knuth.brownes.org>,
>Christopher B. Browne <cbbr...@hex.net> wrote:
>>
>>four components:
>>a) Suitable changes to the C Language to support the "greater than
>>32 bit values" that are necessary to the purpose.
>
>opaque type - NOTHING guarentees that time_t is an int or a long and not
>a struct or a union [other than it must return ((time_t)-1) on errors].
I think the C standard requires it to be an arithmetic type.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Paul D. Smith
js> Not necessary, really. Part of the reason for time_t is that it's
js> an opaque type - NOTHING guarentees that time_t is an int or a
js> long and not a struct or a union [other than it must return
js> ((time_t)-1) on errors].
Not quite true; the C Standard guarantees that time_t and clock_t are
"arithmetic types capable of representing times" (ANSI C89 section
4.12.1). They can't be a struct or union.
--
-------------------------------------------------------------------------------
Paul D. Smith <psm...@baynetworks.com> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
Russ Allbery
> Jonathan Stott <jstott...@poly.phys.cwru.edu> wrote:
>> Not necessary, really. Part of the reason for time_t is that it's an
>> opaque type - NOTHING guarentees that time_t is an int or a long and
>> not a struct or a union [other than it must return ((time_t)-1) on
>> errors].
> I think the C standard requires it to be an arithmetic type.
difftime(3C)
C Library Functions
29 Dec 1996
NAME
difftime - computes the difference between two calendar times
SYNOPSIS
#include <time.h>
double difftime(time_t time1, time_t time0);
DESCRIPTION
difftime() computes the difference between two calendar times.
difftime() returns the difference (time1-time0) expressed in seconds
as a double. This function is provided because there are no general
arithmetic properties defined for type time_t.
--
Russ Allbery (r...@stanford.edu) <URL:http://www.eyrie.org/~eagle/>
Peter Seebach
Russ Allbery <r...@stanford.edu> wrote:
>Barry Margolin <bar...@bbnplanet.com> writes:
>> Jonathan Stott <jstott...@poly.phys.cwru.edu> wrote:
>>> Not necessary, really. Part of the reason for time_t is that it's an
>>> opaque type - NOTHING guarentees that time_t is an int or a long and
>>> not a struct or a union [other than it must return ((time_t)-1) on
>>> errors].
>> I think the C standard requires it to be an arithmetic type.
It does. 7.12.1 "which are arithmetic types capable of representing times".
> difftime() computes the difference between two calendar times.
> difftime() returns the difference (time1-time0) expressed in seconds
> as a double. This function is provided because there are no general
> arithmetic properties defined for type time_t.
Yes. In particular, you can't tell what it counts in. You know that, given
time_t t1, t2, t3;
t1 = time(NULL);
t2 = time(NULL);
you can do
t3 = t2 - t1;
but you have no idea what the result will be. You can't tell if it's measured
in years or seconds, whether it's floating or integer... So you still need
difftime.
Paul D. Smith
ra> difftime() computes the difference between two calendar
ra> times. difftime() returns the difference (time1-time0)
ra> expressed in seconds as a double. This function is provided
ra> because there are no general arithmetic properties defined
ra> for type time_t.
It's true that the types don't have arithmetic properties; nonetheless,
they are required to be arithmetic types.
That is, they could be some encoded form of date where the first N bits
are the time, the next M bits are the day, etc. where comparison or
arithmetic operators (subtraction, etc.) wouldn't work... but they still
have to be arithmetic types.
It should be noted we're talking about ISO standard C here; if (as the
subject implies) we want to restrict ourselves to C on UNIX, then all
the UNIX specs (POSIX, SingleUNIX, etc.) explicitly require time_t to be
the number of seconds since the epoch, thus you can be assured of being
able to do comparisons, arithmetic, etc. on a UNIX system.
It's just that your code won't necessarily port to non-UNIX, standard C
environments.
Russ Allbery
> It should be noted we're talking about ISO standard C here; if (as the
> subject implies) we want to restrict ourselves to C on UNIX, then all
> the UNIX specs (POSIX, SingleUNIX, etc.) explicitly require time_t to be
> the number of seconds since the epoch, thus you can be assured of being
> able to do comparisons, arithmetic, etc. on a UNIX system.
> It's just that your code won't necessarily port to non-UNIX, standard C
> environments.
I'm curious if using difftime() religiously may also make the code easier
to port to an implementation that doesn't have a 2038 problem. Hm. After
thinking about it for a moment, probably not....
Russ Allbery
> Russ Allbery <r...@stanford.edu> wrote:
>> DESCRIPTION
>> difftime() computes the difference between two calendar times.
>> difftime() returns the difference (time1-time0) expressed in seconds
>> as a double. This function is provided because there are no general
>> arithmetic properties defined for type time_t.
> The man page is correct : there are no useful defined arithmetic
> properties for time_t. However, time_t _is_ defined to be an arithmetic
> type of some description by the ISO C standard.
A definition that I find to be somewhat amusing. I'm sure that it makes
sense in the context of the standard, but I think that basically means
that as far as the average programmer is concerned, it's not a "number"
and shouldn't be used as one. An arithmetic type with no defined
properties basically isn't, in practice.
Tim Smith
>> problem now then to put it off for years. The Y2K problem happened
>> because of the inability of most corporations to think in the long
>> term. (Well, to be accurate, it was initially spawned out of a need
>> to save memory,
>
>Ha ha ha! Saving memory, indeed.
You laugh, but the first poster is correct for many old programs. If you
are paying thousands of dollars per kilobyte, saving a couple bytes in every
record of a database adds up very fast!
--Tim Smith
Robert Brady
>NAME
> difftime - computes the difference between two calendar times
>SYNOPSIS
> #include <time.h>
> double difftime(time_t time1, time_t time0);
>DESCRIPTION
> difftime() computes the difference between two calendar times.
> difftime() returns the difference (time1-time0) expressed in seconds
> as a double. This function is provided because there are no general
> arithmetic properties defined for type time_t.
The man page is correct : there are no useful defined arithmetic
properties for time_t. However, time_t _is_ defined to be an arithmetic
type of some description by the ISO C standard.
--
Robert.
Barry Margolin
The big problem is in trying to support binary compatibility.
If all you cared about was source compatibility, then it would be
sufficient for everything to use time_t. When the system changes its
representation of time_t to int64, everything would have to be recompiled
and it would all work.
But binary compatibility messes this up. If you don't recompile
everything, then there will be old programs that use 32-bit time_t passing
them to new libraries that expect 64-bit time_t.
This isn't too different from some of the issues surrounding large file
support these days.
Peter Seebach
Russ Allbery <r...@stanford.edu> wrote:
>A definition that I find to be somewhat amusing. I'm sure that it makes
>sense in the context of the standard, but I think that basically means
>that as far as the average programmer is concerned, it's not a "number"
>and shouldn't be used as one. An arithmetic type with no defined
>properties basically isn't, in practice.
t1 != t2
Russ Allbery
>> A definition that I find to be somewhat amusing. I'm sure that it
>> makes sense in the context of the standard, but I think that basically
>> means that as far as the average programmer is concerned, it's not a
>> "number" and shouldn't be used as one. An arithmetic type with no
>> defined properties basically isn't, in practice.
> t1 != t2
I can do that with pointers too, and pointers aren't something I'd think
of as a "number." But it's possible that's what "arithmetic type" means
in the standard.
William Pentney
Barry Margolin wrote:
> I think the C standard requires it to be an arithmetic type.
In any case, if time_t was a struct, it would cause problems for any program in
which time_t variables are assigned to each other, unless C was changed to support
deep copy (which is almost certainly just too much to ask).
- Bill
Kai Henningsen
Oh? You think there's anything wrong with the following program?
int main(int argc, char *argv[])
{
struct {
int a;
int b;
int c;
} s1, s2;
s1 = s2;
return 0;
}
gcc -Wall -ansi -pedantic certainly doesn't think so. And from my reading
of the standard, neither do ANSI or ISO.
Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
- Russ Allbery (r...@stanford.edu)
William C. Cheng
William Pentney <wmpe...@adelphia.net> wrote:
>A question about UNIX/Linux re: the year 2038 problem ...
>
>it has been, I'm about to make a fool of myself; feel free to set me
>straight.) When will this be dealt with?
>
>Some of you may laugh and say that I'm thinking just a bit too far
>ahead. But I'm very serious. It would be far better to resolve this
>because of the inability of most corporations to think in the long term.
>(Well, to be accurate, it was initially spawned out of a need to save
>would not be so monopolized by short-term considerations. This problem
>should be dealt with in Linux (or GNU/Linux, if you prefer). If nothing
>else, we can brag about the Linux "Year 64K problem" or whatever upon
>its resolution.
The big lesson learned from Y2K is that one needs to be aware of
potential date/time problems! There's nothing do be done with
UNIX/Linux about the Y2038 problem other than being careful what
you code because it may live till Y2038.
For example, if you use time(), be aware that it can overflow. It's
like when you add 2 numbers, it's your responsibility to make sure
that overflow or underflow cannot occur. It's also like when you
copy data from the commandline or a user input, you need to be sure
that you cannot get a buffer overflow so that your program is not a
security risk.
For time() and time_t, if you use wrapper functions and wrapper data
types, you will be able to spend 5 seconds updating your code when
something like time64() or a similar solution comes out; make sure
that you never write out the value returned by time() to storage; etc.
--
Bill Cheng // bill....@acm.org <URL:http://bourbon.cs.umd.edu:8001/william/>
Paul Eggert
>For example, if you use time(), be aware that it can overflow...
>For time() and time_t, if you use wrapper functions and wrapper data
>types, you will be able to spend 5 seconds updating your code when
>something like time64() or a similar solution comes out
There's a much simpler solution: just go on using time_t and time ().
Unix suppliers are already updating time_t to be a 64-bit type. As far
as I know, this first happened with NetBSD on Alphas, but it's now
starting to percolate into other systems; e.g. 64-bit Solaris 7 has
64-bit time_t. I assume that GNU/Linux will follow suit one of these
days, at least on 64-bit hosts.
So you shouldn't need to use wrappers, or change your code at all:
all you should need to do is recompile.
Russ Allbery
> There's a much simpler solution: just go on using time_t and time ().
> Unix suppliers are already updating time_t to be a 64-bit type. As far
> as I know, this first happened with NetBSD on Alphas, but it's now
> starting to percolate into other systems; e.g. 64-bit Solaris 7 has
> 64-bit time_t. I assume that GNU/Linux will follow suit one of these
> days, at least on 64-bit hosts.
> So you shouldn't need to use wrappers, or change your code at all: all
> you should need to do is recompile.
Unless you write time_t out to storage. So don't do that.
Peter Seebach
Kai Henningsen <kaih=7INNT...@khms.westfalen.de> wrote:
>Oh? You think there's anything wrong with the following program?
Hmm.
>int main(int argc, char *argv[])
>{
> struct {
> int a;
> int b;
> int c;
> } s1, s2;
> s1 = s2;
> return 0;
>}
>gcc -Wall -ansi -pedantic certainly doesn't think so. And from my reading
>of the standard, neither do ANSI or ISO.
Actually, we do. You have an object 's2' which is indeterminately-valued,
then you read from it. Access to indeterminately-valued objects is undefined
behavior in C90.
;-)
(The code is still invalid in C9X, but I believe the indeterminately-valued
magic got moved around, and now your problem is that 's2.a' may be a thing
called a "trap representation", which is a magic sequence of bits which cannot
be accessed.)
Glen Turner
> There's a much simpler solution: just go on using time_t and time ().
> Unix suppliers are already updating time_t to be a 64-bit type. As far
> as I know, this first happened with NetBSD on Alphas, but it's now
> starting to percolate into other systems; e.g. 64-bit Solaris 7 has
> 64-bit time_t. I assume that GNU/Linux will follow suit one of these
> days, at least on 64-bit hosts.
My understanding is that Linux plans to move to `64-bit' time_t
after gcc supports C9x (so that `long long' becomes an standard C
arithmetic type and thus a candidate for time_t's implementation).
This will break application code in 2038 on 32-bit int machines,
most particularly:
time_t t;
t = time(NULL);
printf("time() is %lu\n", (unsigned long)t);
which is currently the most portable way of printing
epoch time values under UNIX. This code has to change
for C9X as `long long' becomes the largest standard type.
--
Glen Turner Network Specialist
Tel: (08) 8303 3936 Information Technology Services
Fax: (08) 8303 4400 The University of Adelaide 5005
Email: glen....@adelaide.edu.au South Australia
David Kastrup
> Paul Eggert wrote:
>
> > There's a much simpler solution: just go on using time_t and time ().
> > Unix suppliers are already updating time_t to be a 64-bit type. As far
> > as I know, this first happened with NetBSD on Alphas, but it's now
> > starting to percolate into other systems; e.g. 64-bit Solaris 7 has
> > 64-bit time_t. I assume that GNU/Linux will follow suit one of these
> > days, at least on 64-bit hosts.
>
> My understanding is that Linux plans to move to `64-bit' time_t
> after gcc supports C9x (so that `long long' becomes an standard C
> arithmetic type and thus a candidate for time_t's implementation).
>
> This will break application code in 2038 on 32-bit int machines,
> most particularly:
>
> time_t t;
>
> t = time(NULL);
> printf("time() is %lu\n", (unsigned long)t);
>
> which is currently the most portable way of printing
> epoch time values under UNIX. This code has to change
> for C9X as `long long' becomes the largest standard type.
The above is not at all a "portable" way of printing epoch time
values. The portable way is to convert your wanted "Epoch" into
time_t with the appropriate functions, then use difftime on your time
and the converted Epoch.
Peter Seebach
Glen Turner <glen....@adelaide.edu.au> wrote:
>My understanding is that Linux plans to move to `64-bit' time_t
>after gcc supports C9x (so that `long long' becomes an standard C
>arithmetic type and thus a candidate for time_t's implementation).
I hope they use 'int64_t', not 'long long'.
>which is currently the most portable way of printing
>epoch time values under UNIX. This code has to change
>for C9X as `long long' becomes the largest standard type.
intmax_t and '%jd'. It woulda been '%md', but apparently one of the
library vendors (glibc, I think, but I could be wrong) decided that when
ANSI said "all lowercase letters are reserved for future standardization",
they meant "all lowercase letters except m".
Kai Henningsen
> In article <7INNT...@khms.westfalen.de>,
> Kai Henningsen <kaih=7INNT...@khms.westfalen.de> wrote:
> >Oh? You think there's anything wrong with the following program?
>
> Hmm.
>
> >int main(int argc, char *argv[])
> >{
> > struct {
> > int a;
> > int b;
> > int c;
> > } s1, s2;
> > s1 = s2;
> > return 0;
> >}
>
> >gcc -Wall -ansi -pedantic certainly doesn't think so. And from my reading
> >of the standard, neither do ANSI or ISO.
>
> Actually, we do. You have an object 's2' which is indeterminately-valued,
> then you read from it. Access to indeterminately-valued objects is
> undefined behavior in C90.
In fact, I wondered if gcc would object to that while writing the code.
But it doesn't. Not even if I explicitely say -Wuninitialized. Given that
the code is extremely simple, I guess that may count as a bug.
And I always wanted to have a program that made blue kobolds fly out of my
nose. So there!
Paul Eggert
>My understanding is that Linux plans to move to `64-bit' time_t
>after gcc supports C9x (so that `long long' becomes an standard C
>arithmetic type and thus a candidate for time_t's implementation).
They shouldn't wait that long. Linux needs 64-bit off_t _now_,
so that files can be larger than 2 GB.
> t = time(NULL);
> printf("time() is %lu\n", (unsigned long)t);
>which is currently the most portable way of printing
>epoch time values under UNIX.
No, that should still work. Anybody who wants to make time_t longer
than long should have their head examined. It will break lots of code.
Linux should make long 64 bits before making time_t 64 bits. That's
what everyone else is doing (e.g. HP, IBM, Sun, SGI), for lots of good
reasons. If the Linux folks are planning otherwise, someone should set
them straight. We just had a long discussion about this in
comp.std.c. Even Microsoft isn't so crazy as to redefine standard C
types to be longer than long.
(It's ok to make off_t longer than long, as off_t is not a standard C type.)
Paul D. Smith
>> >int main(int argc, char *argv[])
>> >{
>> > struct {
>> > int a;
>> > int b;
>> > int c;
>> > } s1, s2;
>> > s1 = s2;
>> > return 0;
>> >}
>> >gcc -Wall -ansi -pedantic certainly doesn't think so. And from my
>> >reading of the standard, neither do ANSI or ISO.
>> Actually, we do. You have an object 's2' which is
>> indeterminately-valued, then you read from it. Access to
>> indeterminately-valued objects is undefined behavior in C90.
kh> In fact, I wondered if gcc would object to that while writing the
kh> code. But it doesn't. Not even if I explicitely say
kh> -Wuninitialized. Given that the code is extremely simple, I guess
kh> that may count as a bug.
Nope. As the manual points out, uninitialized memory access checks are
only done if you enable optimization; the command line above doesn't
have any optimization on.
And, if you do enable optimization, there's a chance that the optimizer
will just get rid of all that code, since it's obviously useless, and
wouldn't warn about it.
David Kastrup
> Nope. As the manual points out, uninitialized memory access checks are
> only done if you enable optimization; the command line above doesn't
> have any optimization on.
>
> And, if you do enable optimization, there's a chance that the optimizer
> will just get rid of all that code, since it's obviously useless, and
> wouldn't warn about it.
Well, it could also replace it by the code required to let blue demons
fly out of your nose.
Alan Braggins
> >My understanding is that Linux plans to move to `64-bit' time_t
> >after gcc supports C9x (so that `long long' becomes an standard C
> >arithmetic type and thus a candidate for time_t's implementation).
> No, that should still work. Anybody who wants to make time_t longer
> than long should have their head examined. It will break lots of code.
>
> Linux should make long 64 bits before making time_t 64 bits. That's
> what everyone else is doing (e.g. HP, IBM, Sun, SGI), for lots of good
> reasons.
They have 32-bit ABI's as well as 64-bit ones, also for good reasons.
Running Linux in 2039 on a 32-bit machine, having long 32 bits and
time_t 64 bits will make sense.
Paul D. Smith
dk> psm...@baynetworks.com (Paul D. Smith) writes:
>> Nope. As the manual points out, uninitialized memory access checks are
>> only done if you enable optimization; the command line above doesn't
>> have any optimization on.
>>
>> And, if you do enable optimization, there's a chance that the optimizer
>> will just get rid of all that code, since it's obviously useless, and
>> wouldn't warn about it.
dk> Well, it could also replace it by the code required to let blue
dk> demons fly out of your nose.
I think the EGCS folks changed that to beer-swilling penguins,
actually.
Now _that_ was some fancy coding, for sure! :)
Paul Eggert
>egg...@twinsun.com (Paul Eggert) writes:
>> No, that should still work. Anybody who wants to make time_t longer
>> than long should have their head examined. It will break lots of code.
>>
>> Linux should make long 64 bits before making time_t 64 bits. That's
>> what everyone else is doing (e.g. HP, IBM, Sun, SGI), for lots of good
>> reasons.
>They have 32-bit ABI's as well as 64-bit ones, also for good reasons.
Obviously. All the commercial vendors have kept time_t 32 bits on
32-bit ABIs. That's the only thing that makes any sense; otherwise,
too many programs break. Linux should do the same. If you want
a 64-bit time_t, use an ABI with 64-bit int or long.
>Running Linux in 2039 on a 32-bit machine, having long 32 bits and
>time_t 64 bits will make sense.
That's not worth worrying about. Only museums will be running Linux in
2039 on 32-bit machines.
Lynn Winebarger
Paul Eggert <egg...@twinsun.com> wrote:
>Alan Braggins <ar...@ncipher.com> writes:
>
>That's not worth worrying about. Only museums will be running Linux in
>2039 on 32-bit machines.
Except possibly people in 3rd world countries or the poor.
Lynn
David Kastrup
Sure, and people will run their toasters on 64-Bit processors. Face
it, even now the most-sold processors are 8-Bit processors. This is
because most processors are used in gizmos, electronic stuff and
things because they are cheaper than custom logic.
Even a typical PC sold today will contain at least one 8-Bit processor
(the keyboard controller).
The year 2000 problem (an 8-Bit problem, really) did not go away
because we now feel that only fools will use anything but 32-Bit
processors. The s2G problem will not go away because maybe at that
time people will think only backward persons would be using a 32-Bit
processor.
Saying "oh we won't be using such outdated formats and programs in
2000 anymore" are what caused the Y2K problem. It will be causing the
s2G problem, too, and very likely the s4G problem as well.
Fergus Henderson
>Glen Turner <glen....@adelaide.edu.au> writes:
>
>>My understanding is that Linux plans to move to `64-bit' time_t
>>after gcc supports C9x (so that `long long' becomes an standard C
>>arithmetic type and thus a candidate for time_t's implementation).
>
>They shouldn't wait that long. Linux needs 64-bit off_t _now_,
>so that files can be larger than 2 GB.
Yes, but off_t and time_t are two separate issues.
They don't have to be solved at the same time.
>(It's ok to make off_t longer than long, as off_t is not a standard C type.)
Indeed. So it might well make sense to change to 64-bit off_t soon,
e.g. at the next major release of libc. But changing to 64-bit time_t
should wait until well after gcc supports C9X.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
Paul Eggert
>So it might well make sense to change to 64-bit off_t soon,
>e.g. at the next major release of libc. But changing to 64-bit time_t
>should wait until well after gcc supports C9X.
No, 64-bit time_t should be decoupled from C9x.
C9x allows system types to be longer than long, but this implementation
freedom should be resisted, not exploited, since it's incompatible with
C89. Linux would break all programs that assume C89 or K&R semantics
if it made time_t longer than long. This is a very large set of
programs; it includes most of the GNU programs that I help maintain,
starting with Emacs.
GNU application programmers will not be able to insist on C9x semantics
for at least a decade. Until C9x is universal, they will have to write
code that is compatible with both C89 and C9x. So it's very unwise to
rely on this incompatible change to the C language, at least if you
want to make the change before, say, 2015. In the meantime, if you
want to grow time_t, you're much better off growing `long' to 64 bits,
and letting time_t grow with it. That way, C89 and K&R C programs will
continue to work.
Paul Eggert
>Paul Eggert <egg...@twinsun.com> wrote:
>>Only museums will be running Linux in 2039 on 32-bit machines.
> Except possibly people in 3rd world countries or the poor.
40 years ago, a typical architecture was a Univac. Now, even 3rd world
countries and the poor can afford computers whose computational
abilities greatly that of a circa 1959 Univac. In 2039, nobody outside
of museums will bother running today's machines; it won't be worth the
aggravation to the poor, any more than a poor person today would want
to run a Univac.
By the way, by ``32-bit machine'', I mean a machine where `long' is
only 32-bits. By this definition, even the x86 is a 64-bit machine if
you compile with the right options. This is basically a compiler and
library issue, not a processor issue.
David Kastrup
> owin...@ezinfo.ucs.indiana.edu (Lynn Winebarger) writes:
>
> >Paul Eggert <egg...@twinsun.com> wrote:
> >>Only museums will be running Linux in 2039 on 32-bit machines.
>
> > Except possibly people in 3rd world countries or the poor.
>
> 40 years ago, a typical architecture was a Univac. Now, even 3rd world
> countries and the poor can afford computers whose computational
> abilities greatly that of a circa 1959 Univac. In 2039, nobody outside
> of museums will bother running today's machines; it won't be worth the
> aggravation to the poor, any more than a poor person today would want
> to run a Univac.
If people could get it into their heads that the danger of Y2K
problems does not merely stem from what is used in personal
workstations, I'd be relieved. Most processors used today are 8-Bit
processors, because they are cheaper than ASICs in many cases. Even
if you are buying a personal computer, chances are that you are buying
at least one or two 8-bit processors along (for example, the keyboard
controller). You can hardly buy any electronic device nowadays which
does not include some lousy processor as part of the bargain.
Certainly some industrial control circuits will not use 64-bit
processors even in the very far future. Those are the circuits that
will typically be used in nuclear plants.
Apart from which this does not help anything. Sure, the s2G problem
is basically a 32-bit problem. But the Y2K problem was basically an
8-bit problem, yet many many many 32- and 16-bit systems are affected
by it.
Kai Henningsen
> %% kaih=7IOez...@khms.westfalen.de (Kai Henningsen) writes:
>
> >> >int main(int argc, char *argv[])
> >> >{
> >> > struct {
> >> > int a;
> >> > int b;
> >> > int c;
> >> > } s1, s2;
> >> > s1 = s2;
> >> > return 0;
> >> >}
>
> >> >gcc -Wall -ansi -pedantic certainly doesn't think so. And from my
> >> >reading of the standard, neither do ANSI or ISO.
>
> >> Actually, we do. You have an object 's2' which is
> >> indeterminately-valued, then you read from it. Access to
> >> indeterminately-valued objects is undefined behavior in C90.
kh>> In fact, I wondered if gcc would object to that while writing the
kh>> code. But it doesn't. Not even if I explicitely say
kh>> -Wuninitialized. Given that the code is extremely simple, I guess
kh>> that may count as a bug.
> Nope. As the manual points out, uninitialized memory access checks are
> only done if you enable optimization; the command line above doesn't
> have any optimization on.
Well, I *did* test it with -O9.
> And, if you do enable optimization, there's a chance that the optimizer
> will just get rid of all that code, since it's obviously useless, and
> wouldn't warn about it.
Getting rid of that much code (i.e., 100%) should certainly elicit a
warning of some kind, no?
Kai Henningsen
> In article <375BB8EF...@adelaide.edu.au>,
> Glen Turner <glen....@adelaide.edu.au> wrote:
> >My understanding is that Linux plans to move to `64-bit' time_t
> >after gcc supports C9x (so that `long long' becomes an standard C
> >arithmetic type and thus a candidate for time_t's implementation).
>
> I hope they use 'int64_t', not 'long long'.
My includes (which aren't the newest glibc includes) define int64_t in
<sys/types.h>, but don't actually use it for anything.
> intmax_t and '%jd'. It woulda been '%md', but apparently one of the
> library vendors (glibc, I think, but I could be wrong) decided that when
> ANSI said "all lowercase letters are reserved for future standardization",
> they meant "all lowercase letters except m".
From the glibc docs, printf("%m") == printf("%s", strerror(errno)). Or
that's how I understand it - no time to test it right now. Doesn't seem
all that useful to me, I must say.
Paul D. Smith
>> intmax_t and '%jd'. It woulda been '%md', but apparently one of
>> the library vendors (glibc, I think, but I could be wrong) decided
>> that when ANSI said "all lowercase letters are reserved for future
>> standardization", they meant "all lowercase letters except m".
kh> From the glibc docs, printf("%m") == printf("%s",
kh> strerror(errno)). Or that's how I understand it - no time to test
kh> it right now. Doesn't seem all that useful to me, I must say.
Agreed; the decision to add this to glibc was a mistake, IMO. Hey,
everyone makes 'em.
However, it irks me that the standards committee apparently decided to
forgo using this specifier solely on the strength of the glibc docs.
First, no portable programs would ever use this since it requires glibc.
This, of course, includes all GNU programs themselves.
Second, except for Linux I know of no platforms that use glibc; glibc
ain't GCC. Last time I tried it I couldn't even build glibc 2.x on
Solaris, much less use it.
In other words, I'll bet you could count on the fingers of one hand the
programs that actually use this feature.
Seems like a very silly reason to not use %m, esp. since it quite
clearly violates the C89 standard. I wonder, did anyone in the
committee go ask the glibc folks what they thought? I'll bet they
wouldn't care much.
Lynn Winebarger
Paul Eggert <egg...@twinsun.com> wrote:
>owin...@ezinfo.ucs.indiana.edu (Lynn Winebarger) writes:
>> Except possibly people in 3rd world countries or the poor.
>
>40 years ago, a typical architecture was a Univac. Now, even 3rd world
>countries and the poor can afford computers whose computational
>abilities greatly that of a circa 1959 Univac. In 2039, nobody outside
>of museums will bother running today's machines; it won't be worth the
>aggravation to the poor, any more than a poor person today would want
>to run a Univac.
For one thing, there weren't as many Univacs made as there will be
functional x86 systems with usable software in 40 years. For another, I
think you must have a pretty rosy picture of what options are available
to these folks. Just because _you_ might not be willing to use it in 40
years does not mean there won't be plenty of people who wouldn't find
them damn useful.
Lynn
Paul Eggert
>Paul Eggert <egg...@twinsun.com> wrote:
>>40 years ago, a typical architecture was a Univac.
>I think you must have a pretty rosy picture of what options are available
>to [poor] folks.
Once computers become sufficiently obsolete, they do not become
cheaper: they become more expensive. 40 years from now, nobody, not
even the poorest of the poor, will try to get work done on today's
equipment. They'll use circa-2030 equipment instead -- circa-2020 at
the worst.
For what it's worth, I'm typing this message on an old, old machine,
whose hardware hasn't been upgraded since the day I bought it. It's on
its last legs, though. It won't run enough of today's software, even
the free stuff. If I searched hard I could probably find someone in a
100-mile radius who would use it and not scrap it, but it's not worth
my time to do the search; and five years from now nobody at all will
want it for anything but scrap.
My barely-useful machine is only eight years old.
In my garage I have a PDP-11 that hasn't been powered on for over a
decade. You can't get personal software for it anymore. Nobody would
want to run the old software that's sitting on its disk. It's
definitely a museum piece; i.e. nobody would run it except for
amusement.
My useless machine is about twenty years old.
So, it's easy to foresee that nobody will be interested in today's PCs
40 years from now, except for amusement.
This is all a bit off the topic of Y2038 problems -- as I mentioned
earlier, that's really a library and compiler issue, not a processor
issue. The main argument is about subtle implementation details in the
software upgrade strategy; the processor is relatively unimportant.
Geoffrey KEATING
> Getting rid of that much code (i.e., 100%) should certainly elicit a
> warning of some kind, no?
You would think so, but it's amazing how many routines consist, for instance,
of debugging statements that are compiled out.
--
Geoff Keating <Geoff....@anu.edu.au>
William C. Cheng
>
>> There's a much simpler solution: just go on using time_t and time ().
>> Unix suppliers are already updating time_t to be a 64-bit type. As far
>> as I know, this first happened with NetBSD on Alphas, but it's now
>> starting to percolate into other systems; e.g. 64-bit Solaris 7 has
>> 64-bit time_t. I assume that GNU/Linux will follow suit one of these
>> days, at least on 64-bit hosts.
>
>after gcc supports C9x (so that `long long' becomes an standard C
>arithmetic type and thus a candidate for time_t's implementation).
>
>most particularly:
>
> time_t t;
>
> printf("time() is %lu\n", (unsigned long)t);
>
>which is currently the most portable way of printing
>for C9X as `long long' becomes the largest standard type.
Again, doing I/O with the value returned by time() is a bad idea!
If you want to print time information and use time(), do:
time_t t;
time(&t);
printf("%s", ctime(&t));
--
Bill Cheng // bill....@acm.org <URL:http://bourbon.cs.umd.edu:8001/william/>
Paul Eggert
>If you want to print time information and use time(), do:
> time_t t;
> time(&t);
> printf("%s", ctime(&t));
That's nice in principle, but there are some good reasons not to do it
that way:
* It's slow.
* It doesn't work for time deltas.
* Many protocols require the number of seconds since an epoch;
for those protocols, a human-readable date is not appropriate.
* It's tricky to get right. Your code is not production-quality,
since the output can be ambiguous (e.g. during a DST changeover).
Obviously the last point can be fixed for your little example by
outputting GMT instead -- but then try to write portable C code that
parses the resulting string back to a time_t; it's not easy at all.
See Samba's source/lib/time.c for some of the issues in this area.
In real code, ctime is often _not_ the way to go.
Kai Henningsen
> If people could get it into their heads that the danger of Y2K
> problems does not merely stem from what is used in personal
> workstations, I'd be relieved. Most processors used today are 8-Bit
> processors, because they are cheaper than ASICs in many cases. Even
And most of them don't care about dates.
It's only computers that care about dates that matter for this problem.
What's more, we're talking *Unix* here. I suspect the number of embedded
Unix systems is not vastly larger than the number of non-embedded Unix
systems - if it is larger at all.
If people could get it into their head that mindless panic never helped
anyone ...
> if you are buying a personal computer, chances are that you are buying
> at least one or two 8-bit processors along (for example, the keyboard
> controller).
And none of those will care about dates, and none of those will run Unix.
So for this particular discussion, they're completely irrelevant.
> Apart from which this does not help anything. Sure, the s2G problem
> is basically a 32-bit problem. But the Y2K problem was basically an
> 8-bit problem, yet many many many 32- and 16-bit systems are affected
> by it.
Sorry, but the Y2K problem was never an 8-bit problem for any reasonable
definition of those words.
Kai Henningsen
> In article <7jlmuc$cn4$1...@shade.twinsun.com>,
> Paul Eggert <egg...@twinsun.com> wrote:
> >owin...@ezinfo.ucs.indiana.edu (Lynn Winebarger) writes:
> >> Except possibly people in 3rd world countries or the poor.
> >
> >40 years ago, a typical architecture was a Univac. Now, even 3rd world
> >countries and the poor can afford computers whose computational
> >abilities greatly that of a circa 1959 Univac. In 2039, nobody outside
> >of museums will bother running today's machines; it won't be worth the
> >aggravation to the poor, any more than a poor person today would want
> >to run a Univac.
>
> For one thing, there weren't as many Univacs made as there will be
> functional x86 systems with usable software in 40 years. For another, I
> think you must have a pretty rosy picture of what options are available
> to these folks.
You mean the type of PCs we're throwing out right and left is "a rosy
picture"? Old 386 type machines, say?
Then where would those people get a Univac from?
Remember, you said yourself that not many were made.
And IIRC, those Univacs need quite a bit more enviroment than a more
modern PC does. Stuff like regulated power, controlled external
temperature and humidity and so on. That alone costs more than a brand-
new, modern PC!
>Just because _you_ might not be willing to use it in 40
> years does not mean there won't be plenty of people who wouldn't find
> them damn useful.
The trend will continue. Mass production drives prices down like crazy. My
personal bet is that in 40 years, a 40 year old computer will actually
cost more (for example, because it needs quite a bit more power) than a 10
year old computer that is 1/10th the size, is 1000 times as powerful, and
was produced at least 10 times as much.
Robert Brady
>However, it irks me that the standards committee apparently decided to
>forgo using this specifier solely on the strength of the glibc docs.
>First, no portable programs would ever use this since it requires glibc.
>This, of course, includes all GNU programs themselves.
>Second, except for Linux I know of no platforms that use glibc; glibc
>ain't GCC. Last time I tried it I couldn't even build glibc 2.x on
>Solaris, much less use it.
glibc is the main C library of GNU/Hurd as well as GNU/Linux.
>In other words, I'll bet you could count on the fingers of one hand the
>programs that actually use this feature.
Indeed. However, there was no pressing need for the standard to use %m as
opposed to %<random-other-thing>
--
Robert
Andreas Schwab
|> %% kaih=7IYIO...@khms.westfalen.de (Kai Henningsen) writes:
|>
|> >> intmax_t and '%jd'. It woulda been '%md', but apparently one of
|> >> the library vendors (glibc, I think, but I could be wrong) decided
|> >> that when ANSI said "all lowercase letters are reserved for future
|> >> standardization", they meant "all lowercase letters except m".
|>
|> kh> From the glibc docs, printf("%m") == printf("%s",
|> kh> strerror(errno)). Or that's how I understand it - no time to test
|> kh> it right now. Doesn't seem all that useful to me, I must say.
|>
|> Agreed; the decision to add this to glibc was a mistake, IMO. Hey,
|> everyone makes 'em.
It probably comes from syslog(2). Instead of reimplementing the
formatting inside syslog it's much easier to just call vsprintf.
%m was added to glibc in Oct 1992.
|> Seems like a very silly reason to not use %m, esp. since it quite
|> clearly violates the C89 standard. I wonder, did anyone in the
|> committee go ask the glibc folks what they thought? I'll bet they
|> wouldn't care much.
I don't think that glibc had *any* influence on the standard. For
example, glibc implements an `a' modifer (for scanf("%s"), means to
allocate the string instead of writing to a supplied buffer; incidentally,
this was added at the same time as %m), but that did not stop the
committee to introduce the %a format.
--
Andreas Schwab "And now for something
sch...@issan.cs.uni-dortmund.de completely different"
sch...@gnu.org
Kalle Olavi Niemitalo
> It probably comes from syslog(2). Instead of reimplementing the
> formatting inside syslog it's much easier to just call vsprintf.
syslog() alone might have caused C9X not to use 'm' as a modifier;
surely more systems have syslog than glibc.
Paul D. Smith
as> I don't think that glibc had *any* influence on the standard. For
as> example, glibc implements an `a' modifer (for scanf("%s"), means
as> to allocate the string instead of writing to a supplied buffer;
as> incidentally, this was added at the same time as %m), but that did
as> not stop the committee to introduce the %a format.
Perhaps; I was on comp.std.c a few months ago when folks I thought were
involved with the standards process fingered glibc's printf as the
reason %m wasn't used. Maybe the people saying this weren't fully
informed. I thought it was weak then, and I still think so.
Christopher Browne
Looking at a more modern situation, there were a *LOT* of VAX systems
that got mothballed, replaced by little MicroVAX boxes, based almost
solely on the fact that the improvement in the *electrical* bill would
pay for the MicroVAX in a pretty brief timeframe. That's what
effectively cancelled the 11/780s and such.
>>Just because _you_ might not be willing to use it in 40
>> years does not mean there won't be plenty of people who wouldn't find
>> them damn useful.
>
>The trend will continue. Mass production drives prices down like crazy. My
>personal bet is that in 40 years, a 40 year old computer will actually
>cost more (for example, because it needs quite a bit more power) than a 10
>year old computer that is 1/10th the size, is 1000 times as powerful, and
>was produced at least 10 times as much.
However, it is not manifestly obvious that the power difference (just to
pick on one component) will be a fundamentally big deal.
It certainly was an important issue for Univacs, VAXen, and other sorts
of "big iron." They were pretty scary to keep running, requiring
extensive environmental controls as well as beaucoup power.
In contrast, a C=64 required 120 VAC, and didn't consume significantly
different power than more modern PCs.
And today's 250 Watt power supplies, that probably run on far less once
the PC has started up, are not *overly* burdensome in a home
environment. A curling iron draws more power than a PC, for instance.
I've still got old "home" computer hardware kicking around, and while it
might be appallingly expensive to build replacement components new,
there appears to be enough used machines in other peoples' garages as to
keep the pricing on Atari 800XLs and Atari STs pretty low.
Overall: 40 years from now, there will doubtless be *massive* changes.
32 bit computer systems are likely to become dominated by 64 bit ones
over the next 5-10 years, which will make the 32 bit stuff disappear
into the woodwork.
BUT. Since there's the quantity as well as "survival of adverse home
conditions" that result from widespread consumer deployment of PCs,
substantial pricing increases are *not* likely, as that would encourage
the "stuff in garages" to emerge back from the woodwork, thus pulling
prices back down...
--
"Java and C++ make you think that the new ideas are like the old ones.
Java is the most distressing thing to hit computing since MS-DOS."
-- Alan Kay
cbbr...@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>
William C. Cheng
Paul Eggert <egg...@twinsun.com> wrote:
>wil...@cs.umd.edu (William C. Cheng) writes:
>
>>If you want to print time information and use time(), do:
>
>> time_t t;
>
>> time(&t);
>> printf("%s", ctime(&t));
>
>That's nice in principle, but there are some good reasons not to do it
>that way:
>
>* It's slow.
Hmm... In Samba's source/lib/time.c, timestring() calls LocalTime()
(which calls gmtime()) and asctime() (if strftime() is not available).
Why is that faster than just calling ctime()?
>* It doesn't work for time deltas.
Well, it's a reponse to a previous poster's code. So it wasn't really
meant to do time deltas!
>* Many protocols require the number of seconds since an epoch;
> for those protocols, a human-readable date is not appropriate.
Sure! But don't these protocols have build-in Y2Something problems
if the number of seconds is supposed to fit in a fixed size field?
>* It's tricky to get right. Your code is not production-quality,
> since the output can be ambiguous (e.g. during a DST changeover).
The code is meant to be an example of something to be use in a
MessageBox() (which is not meant to be read back).
>Obviously the last point can be fixed for your little example by
>outputting GMT instead -- but then try to write portable C code that
>parses the resulting string back to a time_t; it's not easy at all.
>
>See Samba's source/lib/time.c for some of the issues in this area.
>In real code, ctime is often _not_ the way to go.
It certainly looks very elaborate! I hope I will never have to write
time to disk!
John Kodis
> For example, glibc implements an `a' modifer (for scanf("%s"), means
> to allocate the string instead of writing to a supplied buffer;
> incidentally, this was added at the same time as %m),
Another "perhaps not-quite-standard" modifier that I've heard rumors
of is an apostrophie modifier that would insert digit grouping
characters (commas in the US, periods elsewhere) in numbers, such
that...
printf("%'d\n", 12345);
would print
12,345
Has anyone seen such a modifier in use? It's not supported by the
versions of glibc that I've tried, but it sure would be a nice thing
to have available.
-- John Kodis.
Kai Henningsen
> kaih=7IYIO...@khms.westfalen.de (Kai Henningsen) writes:
>
> > Getting rid of that much code (i.e., 100%) should certainly elicit a
> > warning of some kind, no?
>
> You would think so, but it's amazing how many routines consist, for
> instance, of debugging statements that are compiled out.
Aah, but that's a different kind of optimization.
There's elimination of code that cannot be reached (the debugging case),
and there's elimination of code that doesn't have any effects (the case
under discussion).
Code without any effects is practically always an error. ("Practically" to
account for things like "(void)someparam;" to shut up a compiler warning
about unused parameters. Besides, in that case, absence of effect is
explicitely intentional.)
Kai Henningsen
> wil...@cs.umd.edu (William C. Cheng) writes:
>
> >If you want to print time information and use time(), do:
>
> > time_t t;
>
> > time(&t);
> > printf("%s", ctime(&t));
>
> That's nice in principle, but there are some good reasons not to do it
> that way:
>
> * It's slow.
> * It doesn't work for time deltas.
> * Many protocols require the number of seconds since an epoch;
> for those protocols, a human-readable date is not appropriate.
> * It's tricky to get right. Your code is not production-quality,
> since the output can be ambiguous (e.g. during a DST changeover).
* It's not meaningful in an international environment.
> In real code, ctime is often _not_ the way to go.
For human-readable times, I typically use (and that's because I typically
don't need to bother about time zones)
printf("%s",
strftime(buf, sizeof(buf), "%Y-%m-%d %H:%M:%S", localtime(&t)));
No, that's not localized, either, but at least it's internationally
unambiguous (it's one of the ISO time formats). Plus, it sorts just fine,
and is trivially parsable back into a struct tm, should that ever be
necessary.
And if you need those seconds, there's nothing particularly wrong with
just using a decimal representation.
Typical (non-C) use:
find somewhere -printf "%T@ %t %p\n" | sort -n
Kai Henningsen
> And today's 250 Watt power supplies, that probably run on far less once
> the PC has started up, are not *overly* burdensome in a home
> environment. A curling iron draws more power than a PC, for instance.
But you're assuming first world conditions, here. What about an
environment where a steady power source isn't a given? And I assure you
that there are even places in the first world where this is a problem -
more in the US than in Germany, I gather :-) Thus the UPS industry.
Compare that to a notebook, which runs on rechargable batteries. For those
types of environments, it's vastly preferrable. Of course, it's (today)
also vastly more expensive.
Geoffrey KEATING
Works fine for me in glibc 2.1:
$ cat > zz.c <<EOF
#include <stdio.h>
#include <locale.h>
int main(void)
{
setlocale (LC_ALL, "");
printf("%'d\n", 123456789);
return 0;
}
EOF
$ gcc zz.c -o zz
$ LANG=en_AU ./zz
123,456,789
Actually, in countries where you would expect a '.' to be used, in
practise no separator at all is used because it would be too
confusing; this is also the default in the "C" locale. Similarly, in
Australia technically the correct separator is the space character,
but that's not a sane thing to do on computer systems.
--
Geoff Keating <Geoff....@anu.edu.au>
Andreas Schwab
|> wil...@cs.umd.edu (William C. Cheng) writes:
|>
|> >If you want to print time information and use time(), do:
|>
|> > time_t t;
|>
|> > time(&t);
|> > printf("%s", ctime(&t));
|>
|> That's nice in principle, but there are some good reasons not to do it
|> that way:
|>
|> * It's slow.
|> * It doesn't work for time deltas.
You don't use time_t for deltas. You don't know whether time_t is signed
or unsigned, so it's useless. Use difftime instead.
Paul Eggert
>printf("%s",
> strftime(buf, sizeof(buf), "%Y-%m-%d %H:%M:%S", localtime(&t)));
>No, that's not localized, either, but at least it's internationally
>unambiguous (it's one of the ISO time formats). Plus, it sorts just fine,
No, because it generates timestamps that repeat during DST fallbacks.
You'll need to switch from localtime to gmtime to get something that
sorts fine and is unambiguous.
John Kodis
>Works fine for me in glibc 2.1:
>
>$ cat > zz.c <<EOF
>#include <stdio.h>
>#include <locale.h>
>
>int main(void)
>{
> setlocale (LC_ALL, "");
> printf("%'d\n", 123456789);
> return 0;
>}
>EOF
>$ gcc zz.c -o zz
>$ LANG=en_AU ./zz
>123,456,789
Yes, same here once I the LANG variable. That was the piece of the
puzzle that I was missing. Thanks. Oddly, both gcc and egcs complain:
fmt.c:10: warning: unknown conversion type character `'' in format
... but I imagine that this is just a version skew problem.
-- John Kodis.
Paul Eggert
>You don't use time_t for deltas. You don't know whether time_t is signed
>or unsigned, so it's useless. Use difftime instead.
I disagree with you (and so does the source code to Emacs, Samba, etc. :-).
time_t is almost invariably a signed integer, for backwards
compatibility with Unix Version 7, so it's no big deal to assume this.
If you really want to worry about unsigned time_t, you can write code
that will work in that case too; most people don't bother. (The
standards allow time_t to be a floating point type too, but most people
don't bother about that either.)
Also, difftime has its own problems. For example, difftime can lose
information in the common case where time_t is 64 bits and double is
IEEE double.
In careful code, using floating point to compute time_t differences is
asking for trouble. It's typically better to compute with integers if
timestamps are integers.
David Kastrup
> Andreas Schwab <sch...@issan.cs.uni-dortmund.de> writes:
>
> >You don't use time_t for deltas. You don't know whether time_t is signed
> >or unsigned, so it's useless. Use difftime instead.
>
> I disagree with you (and so does the source code to Emacs, Samba, etc. :-).
>
> time_t is almost invariably a signed integer, for backwards
> compatibility with Unix Version 7, so it's no big deal to assume this.
> If you really want to worry about unsigned time_t, you can write code
> that will work in that case too; most people don't bother. (The
> standards allow time_t to be a floating point type too, but most people
> don't bother about that either.)
>
> Also, difftime has its own problems. For example, difftime can lose
> information in the common case where time_t is 64 bits and double is
> IEEE double.
And you are living in the year 4000000AD or so.
--
David Kastrup Phone: +49-234-700-5570
Email: d...@neuroinformatik.ruhr-uni-bochum.de Fax: +49-234-709-4209
Institut für Neuroinformatik, Universitätsstr. 150, 44780 Bochum, Germany
Kai Henningsen
We're talking two different kinds of ambiguous, here (ambiguous to people
in different locales as opposed to ambiguous between two invocations
during DST change).
For what I do, the first kind is important, and the second isn't. (Plus,
as you say, it's easy to switch the priorities around by using gmtime
instead.)
Egil Kvaleberg
> This will break application code in 2038 on 32-bit int machines,
> most particularly:
>
> time_t t;
>
> t = time(NULL);
> printf("time() is %lu\n", (unsigned long)t);
>
> which is currently the most portable way of printing
> epoch time values under UNIX.
I'm just wondering:
What is wrong with the obvious solution for 16 and 32 bit machines?
Defining time_t as "unsigned long" instead of "long".
That would postpone the problem a further 68 years (until 2106), and
would surely suffer from less compatibility problems than any > 32 bit
time_t.
An unsigned "time_t" can still be compared. The only real problem would be
for programs that doesn't use difftime() for calculating time differences,
but instead does "time2-time1" to calculate a signed difference. This
would fail when the difference in time is > 68 years. Common use of
time_t normally does not approach that at all (unless there are machines
with planned uptimes > 68 years?)
Egil
--
Email: eg...@kvaleberg.no Voice: +47 22523641, 92022780 Fax: +47 22525899
Mail: Egil Kvaleberg, Husebybakken 14A, 0379 Oslo, Norway
Home: http://www.kvaleberg.no/
Christopher Browne
<kaih=7IiWv...@khms.westfalen.de> wrote:
>cbbr...@news.hex.net (Christopher Browne) wrote on 11.06.99 in
<7jrj79$sc...@george.sabre.com>:
>> And today's 250 Watt power supplies, that probably run on far less once
>> the PC has started up, are not *overly* burdensome in a home
>> environment. A curling iron draws more power than a PC, for instance.
>
>But you're assuming first world conditions, here. What about an
>environment where a steady power source isn't a given? And I assure you
>that there are even places in the first world where this is a problem -
>more in the US than in Germany, I gather :-) Thus the UPS industry.
I am indeed assuming "First World/New World conditions;" that represents
an extremely large market that can afford to purchase computers.
- Thinking back to the early days of the GNU Project, the computers at
*that* time that could run GNU software were largely in the class of
"big, sensitive boxes requiring power and air conditioning." (VAXen and
the likes.)
- Consider the (perhaps not precisely chronological :-)) sequence of
home-deployed computers from the early days up to now:
- Cromenco
- TRS-80 Model I
- Apple ][
- IBM PC Jr
- IBM PC
- Apple Macintosh
- Compaq Deskpro 386
- AST Bravo
These sorts of computer systems all have a common dependancy on there
being power and environment of what is typically considered of
"residential quality" in "First/New World" countries.
Such expectations have persisted from the 1970s until now; I don't see
good reason to expect these expectations to substantially change in the
near term.
If quality varies *moderately,* a UPS that can filter most of the
problems out costs about $150 USD, which has usually represented not far
from 10% of the cost of a computer system.
Do these represent globally universal properties? Obviously not. The
salient point is that the properties *are* widespread and are widely
assumed.
I don't see it being terribly likely that everyone will get up tomorrow
and decide:
"Oh, we need to start building all the computers to use 5 watt power
supplies."
--
"By your private definition, they were poor, but who cares?. By my
private definition, you are a elm tree." -- Mike Coffin <m...@Eng.Sun.COM>
cbbr...@hex.net- <http://www.hex.net/~cbbrowne/hardware.html>
Paul Eggert
>> Also, difftime has its own problems. For example, difftime can lose
>> information in the common case where time_t is 64 bits and double is
>> IEEE double.
>And you are living in the year 4000000AD or so.
One doesn't need to live in a time to have computations about it.
Even with 32-bit time_t I regularly use time_t on Solaris to compute
timestamps in 1901, and I'm not _that_ old. If I'm doing calculations
involving, say, ice-age dates, I'll be annoyed if difftime keeps
introducing off-by-one (or off-by-more) glitches into my calculations,
when I know that the glitches don't occur with time_t arithmetic.
So I'll compute with time_t. That's the most popular way to compute
time_t differences; very little code uses difftime.
Besides, library code (as opposed to throwaway code) should work
correctly no matter what time is being represented. So library
code should steer clear of difftime.
Paul Eggert
>>> Also, difftime has its own problems. For example, difftime can lose
>>> information in the common case where time_t is 64 bits and double is
>>> IEEE double.
Just to follow up on my own remark:
Another problem with difftime is that, since it's so rarely used,
it's buggy. E.g. on 64-bit Solaris 7 (sparc),
difftime (9223372036854775807, -1536) yields
-9223372036854774784.0, which is an enormous error.
David Kastrup
Kai Henningsen
> On 12 Jun 1999 16:59:00 +0200, Kai Henningsen
> <kaih=7IiWv...@khms.westfalen.de> wrote:
> >cbbr...@news.hex.net (Christopher Browne) wrote on 11.06.99 in
> <7jrj79$sc...@george.sabre.com>:
> >> And today's 250 Watt power supplies, that probably run on far less once
> >> the PC has started up, are not *overly* burdensome in a home
> >> environment. A curling iron draws more power than a PC, for instance.
> >
> >But you're assuming first world conditions, here. What about an
> >environment where a steady power source isn't a given? And I assure you
> >that there are even places in the first world where this is a problem -
> >more in the US than in Germany, I gather :-) Thus the UPS industry.
>
> I am indeed assuming "First World/New World conditions;" that represents
> an extremely large market that can afford to purchase computers.
Well, third world was explicitely mentioned, and so that was part of what
I was thinking about.
> - Thinking back to the early days of the GNU Project, the computers at
> *that* time that could run GNU software were largely in the class of
> "big, sensitive boxes requiring power and air conditioning." (VAXen and
> the likes.)
Oh btw, and how many poor people today would want to run those? :-)
> - Consider the (perhaps not precisely chronological :-)) sequence of
> home-deployed computers from the early days up to now:
> - Cromenco
> - TRS-80 Model I
> - Apple ][
> - IBM PC Jr
> - IBM PC
> - Apple Macintosh
> - Compaq Deskpro 386
> - AST Bravo
You do notice that these have less dependency on nice power than the
above, yes?
There's a trend here.
> These sorts of computer systems all have a common dependancy on there
> being power and environment of what is typically considered of
> "residential quality" in "First/New World" countries.
No, not all that common. My old Apple ][, for example, could survive
conditions that made the light blink (and the Epsom MX-80 printer reset).
I'm pretty certain an old VAX wouldn't have liked that at all.
There's a trend here.
> Such expectations have persisted from the 1970s until now; I don't see
> good reason to expect these expectations to substantially change in the
> near term.
They're already changing.
> If quality varies *moderately,* a UPS that can filter most of the
> problems out costs about $150 USD, which has usually represented not far
> from 10% of the cost of a computer system.
Yes, I'm running one such right now, given that for a certain program I
use, recovering after loss of power (due to someone using a faulty piece
of equipment) is a major PITA.
But the price of UPSen has come down a lot, too. Which effectively
translates into less dependency on a good power environment ...
<AOL together now> There's a trend here. </AOL>
> I don't see it being terribly likely that everyone will get up tomorrow
> and decide:
> "Oh, we need to start building all the computers to use 5 watt power
> supplies."
Of course not, that happens gradually. However, it *is* definitely
happening.
Already notebooks have a far larger market segment that I thought possible
even two years ago, plus there's an onslaught of palmtops, and all of them
get more powerful, fast.
I just don't see why, fourty years from now, someone would *want* to use
today's computers, except as an exercise in retrocomputing. Ten, *maybe*
twenty year old computers, yes - but fourty?! Impossible.
Excepting a major breakdown of the computer industry, of course.
Hell, for something evolving at a slower rate, how many people even use
fourty year old *cars*? That's made-in-1959. I think they're rare even in
the third world. For one thing, you can't get replacement parts except by
taking apart another one.
Kai Henningsen
> David Kastrup <d...@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:
>
> >> Also, difftime has its own problems. For example, difftime can lose
> >> information in the common case where time_t is 64 bits and double is
> >> IEEE double.
>
> >And you are living in the year 4000000AD or so.
>
> One doesn't need to live in a time to have computations about it.
> Even with 32-bit time_t I regularly use time_t on Solaris to compute
> timestamps in 1901, and I'm not _that_ old. If I'm doing calculations
> involving, say, ice-age dates, I'll be annoyed if difftime keeps
> introducing off-by-one (or off-by-more) glitches into my calculations,
> when I know that the glitches don't occur with time_t arithmetic.
> So I'll compute with time_t. That's the most popular way to compute
> time_t differences; very little code uses difftime.
Oh, and how many systems do you know where time_t covers ice-age dates?
Sure, it would be nice to have - but I haven't seen a single
implementation of time_t that had it.
If you rely on something as unportable as this, you might as well
completely forget what the standard says about time handling.
Paul Eggert
>What makes you think 9223372036854775807 is a legal date?
It's not a legal date. It's a time_t value. It's valid on hosts with
64-bit time_t values, like the one I'm typing this message on.
If I use time_t arithmetic, 9223372036854775807 works just fine.
If I use difftime, 9223372036854775807 doesn't work.
Hence I should avoid difftime; it's not reliable in general-purpose
time_t code, at least on my host (64-bit Solaris 7).
Paul Eggert
>how many systems do you know where time_t covers ice-age dates?
64-bit Solaris 7, which is the OS I'm typing this message through,
though admittedly the library is buggy (e.g. the difftime bug I
mentioned). I think NetBSD (on Alphas) was first with 64-bit time_t.
There are probably others. Linux is headed that way.
We've got to do _something_ to handle the Y2038 problem,
and growing time_t to (signed) 64 bits is the consensus solution.
>If you rely on something as unportable as this, you might as well
>completely forget what the standard says about time handling.
I don't rely on it now. I do, however, rely on time_t being an integer
count of seconds since 1970-01-01 00:00:00 UTC; because of tradition
and POSIX.1, this is a pretty safe assumption on the hosts that I'm
interested in porting to. Once we get closer to 2038, it'll also be a
safe assumption that time_t can handle ice-age timestamps, because
time_t will be 64 bits.
Paul Eggert
>1969-12-31 23:59:59 is likely to cause you some problems,
>because it's (time_t)-1 which is used in a few places as an error return.
Yes, but that's true already. The problem of (time_t)-1 is unaffected
by the change from 32-bit to 64-bit time_t.
>I certainly wouldn't expect a random system to be able to handle
>negative time_t values
Perhaps not; but the good ones do, and it's worth encouraging the
others to do better.
>nor would I want to rely on those times being
>_before_ 1970, the system is quite likely to decide that they are
>post-2038.
That would be strange. For one thing, it's contrary to historical
practice. Also, once time_t grows to 64 bits, it's obviously more
useful to keep time_t signed, as that covers more of the interesting
timestamps.
I have heard rumors of POSIX hosts with unsigned time_t, but I've never
actually seen one, or even a solid reference to one. Much of the
time_t code in real programs wouldn't port to unsigned time_t.
Granted, it's usually not too much extra trouble to write code that
will work even if time_t is unsigned, but only compulsive hackers (like
you and me :-) worry about this stuff; most programmers don't bother,
and I can't say I blame them.
Geoffrey KEATING
Ice-age, perhaps. But 1969-12-31 23:59:59 is likely to cause you some
problems, because it's (time_t)-1 which is used in a few places as an
error return.
I certainly wouldn't expect a random system to be able to handle
negative time_t values; nor would I want to rely on those times being
_before_ 1970, the system is quite likely to decide that they are
post-2038.
--
Geoff Keating <Geoff....@anu.edu.au>
Alan Coopersmith
>I certainly wouldn't expect a random system to be able to handle
>negative time_t values;
As one example, Solaris 7 will return EOVERFLOW if you try to stat() a
file with a negative timestamp over NFS (either on the client or server
side).
--
________________________________________________________________________
Alan Coopersmith al...@godzilla.EECS.Berkeley.EDU
Univ. of California at Berkeley http://soar.Berkeley.EDU/~alanc/
aka: alanc@{CSUA,OCF,CS,BMRC,EECS,ucsee.eecs,cory.eecs}.Berkeley.EDU
Andreas Schwab
|> An unsigned "time_t" can still be compared. The only real problem would be
|> for programs that doesn't use difftime() for calculating time differences,
|> but instead does "time2-time1" to calculate a signed difference. This
|> would fail when the difference in time is > 68 years. Common use of
|> time_t normally does not approach that at all (unless there are machines
|> with planned uptimes > 68 years?)
What does the uptime has to do with calendar times? You can have
arbitrary time stamps even if you just booted your system.
Paul Eggert
>What is wrong with the obvious solution for 16 and 32 bit machines?
>Defining time_t as "unsigned long" instead of "long".
First, a lot of code assumes that time_t is signed. It may be sloppy
code, but _I_ don't want to fix it, and most OS suppliers don't either.
Second, it's useful to be able to represent times before 1970.
Third, if you're going to make incompatible changes, you might as well
go to 64-bit time_t; that way you won't have a Y2106 problem.
>The only real problem would be for programs that doesn't use difftime()
(I.e. the vast majority of programs that compute time_t differences. :-)
>for calculating time differences, but instead does "time2-time1"
>to calculate a signed difference. This
>would fail when the difference in time is > 68 years.
It can also fail when the difference is 1 second. If time2 == time1-1,
then time2-time1 yields -1 with signed time_t but would yield
4294967295 if time_t were an unsigned 32-bit quantity.
>Common use of
>time_t normally does not approach that at all (unless there are machines
>with planned uptimes > 68 years?)
time_t is not just the returned value of the time function; programs
also compare stored time_t values. Unsigned time_t will introduce many
bugs, some of which will will be triggered in 2038. If you're going to
that much work, you might as well go to 64 bits and solve the problem
indefinitely.