Date: Mon, 2 Aug 2004 16:26:58 -0400 From: John Cowan <jcowan@reutershealth.com> Message-ID: <20040802202657.GB2655@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@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@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@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