asctime.c

[Robert Elz]

    Date:        Mon, 2 Aug 2004 16:26:58 -0400
    From:        John Cowan <jcowan at reutershealth.com>
    Message-ID:  <20040802202657.GB2655 at skunk.reutershealth.com>

  | "Claims" to compile C code?
  | What if it lies, and actually only accepts Fortran?

That (probably) my C code won't compile, and I'll curse a lot, but
aside from if you're in my immediate vicinity at the time, there
won't be a problem.

  | My computer that I have in my pocket here has only 256 words of RAM, so your
  | program won't "work" on it for very large values of "your program".  I don't
  | see that as a portability failure.

I do, if the code is supposed to be able to work there, looks as if it will
work there, and attempts to work there.


Clive D.W. Feather <clive at demon.net> said:
  | > You'd prefer years with leading zeroes?   Why?
  | Because that's what "constant width" says to me. 

Hmm, one of us is confused.   A constant width field to me is one with
a fixed width (fixed number of bytes used).   That by itself says nothing
about the characters that get put in the field.   As an example, the day
of the month field is also constant width (2 characters), yet is space
filled for values < 10, not zero filled.

Nothing that I've seen cares what characters are in the field (well,
a year is wanted, but spaces, of zeroes isn't too relevant) - that is,
no-one takes the field and tries atoi() (or modern equivalent) on it to
get the value of the year - that would be perverse in the extreme.

What people want is fixed width fields, in fixed places, so parts that
are not wanted can be easily omitted (including especially the trailing \n),
but I have also seen programs take just the time, or just the date (the
first 10 bytes, and then the last 4 - that is: [20..23] - sometimes
other combinations (skip the day of the week and the seconds, ...)

Once again, in a modern program, strftime provides all of that, in
a far easier and more flexible manner, but strftime didn't always exist.

clive at demon.net said:
  | Why not? This started because you claimed programs were relying on the
  | previous specification.

Yes, I have seen many.   I have never seen one that relies on what has been
cited as the current standard.   Never once.   And I look at quite a lot
of code.   New code just doesn't race about parsing asctime (or ctime)
output strings to get the parts of it, old code used to do that all the
time.

clive at demon.net said:
  | I don't believe you can write any code that that statement is true for.
  | Clue: there are C compilers that don't implement printf(). 

Of course, and that's no problem - if my code uses printf, then that
implementation wouldn't compile it (by which I mean producing a fully
linked executable that starts to run).

Programs that fail to compile (or link) aren't a serious problem, they're
fixable.   The problems are programs that seem to work just fine, but then
(just sometimes) don't produce the results they're supposed to produce.

That's the kind of thing that is the problem here.   If the C standards
had simply omitted asctime, and then there were implementations that
didn't bother to provide it at all, then fine.   But providing something
different than what programs have been expecting, with no way for the
program to discover that it isn't going to get on this system the
same behaviour as on all the others, essentially forever, is seriously poor,
and is the very thing that standards are supposed to help prevent, not
promulgate.

kre