peter@sugar.UUCP (09/12/87)
Y'all are missing the point. Why include "gmtime" and "localtime" in Ansi-C (other than to keep the well known false sense of well-being when trying to port UNIX programs to non-UNIX systems), but leave read/write/etc out? It just doesn't seem consistent to me. Since most non-UNIX-based 'C' compilers in the real world implement read and write and *not* gmtime and localtime, you don't even have precedent behind you. Don't get me wrong... I like having gmtime and localtime around. I just think there's a place for read and write as well. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` ^^^^^^^^^^^^^^ Not seismo!soma (blush)
henry@utzoo.UUCP (Henry Spencer) (09/20/87)
> ... Since most non-UNIX-based 'C' compilers > in the real world implement read and write and *not* gmtime and localtime, > you don't even have precedent behind you. You mean, most poorly-written C compilers on rather Unix-like systems. -- "There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry
bill@green.UUCP (Bill Bogstad) (09/21/87)
In article <706@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >Y'all are missing the point. Why include "gmtime" and "localtime" in Ansi-C >(other than to keep the well known false sense of well-being when trying to >port UNIX programs to non-UNIX systems), but leave read/write/etc out? It >just doesn't seem consistent to me. Since most non-UNIX-based 'C' compilers >in the real world implement read and write and *not* gmtime and localtime, >you don't even have precedent behind you. "Most" systems have some type of real-time clock and it would be nice to be able to access the clock from the C language. Having a standard way to do so would be even nicer. The method chosen has been available in the standard unix environment since at least Version 7. Rhetorical question: What about systems without clocks? Answer: What about systems that don't do I/O? (Making stdio vs read/write a mote point. They just have memory mapped registers.) However, "most" systems do allow I/O. Fopen(), fclose(), etc. are provided as the standard way to access this feature (also since at least Version 7). It has been stated by several people that it is very hard to impossible to fully implement the semantics of read/write on some systems. I do not have personal knowledge of such systems, but I am willing to admit their existence. Should the C language standard require things of these systems (a particular form of I/O) that they are incapable of providing? [If you would like, you may consider the above rationalizations on my part to support an already closed mind. Actually, they probably are. BTW, I would also like read/write to be implemented on any system on which it can be.] Bill Bogstad -- Bill Bogstad bogstad@hopkins-eecs-bravo.arpa Work: (301)338-8019 Home: No way. jhunix!{ green!bill | bph_cwjb } The Johns Hopkins University, Biophysics Department, Baltimore MD 21218
edw@ius1.cs.cmu.edu (Eddie Wyatt) (09/22/87)
In article <706@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: > Y'all are missing the point. Why include "gmtime" and "localtime" in Ansi-C > (other than to keep the well known false sense of well-being when trying to > port UNIX programs to non-UNIX systems), but leave read/write/etc out? It I would suspect that there exists some OSs (maybe many) that could not support all of the semantics of read and write. Also to port read, write and any other of the hosts of functions that operate on file descriptors, one would have to port the concept of a FILE DESCRIPTOR into the language. Last point, hasn't ANSI accepted fread and fwrite as part of the Standard C library. So if portable code is an issue, shouldn't you be using them instead of read and write? > just doesn't seem consistent to me. Since most non-UNIX-based 'C' compilers > in the real world implement read and write and *not* gmtime and localtime, No real C Compiler implements read and write - its part of the C library which I consister not part of the language. -- Eddie Wyatt e-mail: edw@ius1.cs.%%%%%%%%
peter@sugar.UUCP (Peter da Silva) (09/25/87)
In article <8617@utzoo.UUCP>, henry@utzoo.UUCP (Henry Spencer) writes: > > ... Since most non-UNIX-based 'C' compilers > > in the real world implement read and write and *not* gmtime and localtime, > > you don't even have precedent behind you. > > You mean, most poorly-written C compilers on rather Unix-like systems. Well, most non-UNIX systems don't even provide enough information to the library to meaningfully implement both gmtime and localtime. The first compiler I've run across with gmtime and localtime is the Aztec 'C' compiler on the Amiga. Both functions give the same results, and neither implement daylight savings time. This is useful? The only C compiler I know of that didn't implement open, close, read, and write was the original BDS-C library on the Z-80. It implemented fopen and fclose with open/close semantics, fprintf with the first argument being an integer, and so on. I suppose this was a well-written compiler. Well, it did run like a demon. It was written in assembly. Wanna come up with some examples? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today? -- Disclaimer: These aren't mere opinions... these are *values*.
peter@sugar.UUCP (Peter da Silva) (09/25/87)
In article <478@green.UUCP>, bill@green.UUCP (Bill Bogstad) writes: > In article <706@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >just doesn't seem consistent to me. Since most non-UNIX-based 'C' compilers > >in the real world implement read and write and *not* gmtime and localtime, > >you don't even have precedent behind you. > > "Most" systems have some type of real-time clock and it would be nice > to be able to access the clock from the C language. Having a standard way > to do so would be even nicer. The method chosen has been available in the > standard unix environment since at least Version 7. But part of the information in gmtime() and localtime() isn't available outside of UNIX: daylight-savings-time-flag, timezone. It's overkill. The standard should provide LOCALTIME with the final "daylight savings time" flag replaced by an innocuous filler that won't encourage people to expect it. GMTIME should not be in the standard at all. Also, what's wrong with time(0)? It's also in the standard, as is a new routine to allow time arithmetic. That would force libraries to have time kept in a useful fashion. The old Aztec 'C' library on the Amiga (which keeps julian time) used MS-DOS pseudo packed decimal format. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today? -- Disclaimer: These aren't mere opinions... these are *values*.
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (09/26/87)
In article <813@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
<The only C compiler I know of that didn't implement open, close, read, and
<write was the original BDS-C library on the Z-80. It implemented fopen and
<fclose with open/close semantics, fprintf with the first argument being an
<integer, and so on. I suppose this was a well-written compiler.
My memory and yours don't agree with each other. I don't have a manual
any more, but I could call Leor and ask. I remember cussing at the BDS
C read/write/open/close because the were tied directly to the CP/M DOS
calls, so that the "how much to read" parameter told how many
CP/M disk records to read.
Likewise, I recall the that the f* routines looked like the "portable
I/O library." I could be mistaken, because I only saw that briefly on
the 370 port of the v6 C compiler/library.
Of course, BDS C was the second C compiler outside the Unix
environment. Leor gets to use the excuse that there wasn't a push to
use Unix-like I/O libraries at the time.
Finally calling BDS C a C compiler is stretching things a little.
While closer to C than Tiny-C or Small-C, it was still missing some
important feature - like statics and initializers. It was a great tool
for building code for z80s and 808[05]s (better than whitesmiths), it
wasn't a tool you'd want to try to port code to.
For another example with "broken" read/write routines, consider the
Software Toolworks C/80 for CP/M-80 and the Heath z80 OS (whatever it
was called). Worked just like the Unix versions, except that the
number of characters read was rounded down to the nearest record
boundary (128 for CP/M, 256 for Heath).
<mike
--
I know the world is flat. Mike Meyer
Don't try tell me that it's round. mwm@berkeley.edu
I know the world stands still. ucbvax!mwm
Don't try to make it turn around. mwm@ucbjade.BITNEThenry@utzoo.UUCP (Henry Spencer) (09/29/87)
> The only C compiler I know of that didn't implement open, close, read, and > write was the original BDS-C library on the Z-80.... > > Wanna come up with some examples? I would be very surprised if the Bell Labs C compilers under OS/360 and whatever it was that ran on the big Honeywell mainframes -- these were among the first C compilers other than the Unix ones -- implemented any of the above. The operating systems were just drastically unsuited to it. It would be nice if people realized that systems like MSDOS are not fair examples of un-Unix-like operating systems, because they in fact were heavily influenced by Unix. -- "There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry
henry@utzoo.UUCP (Henry Spencer) (09/29/87)
> But part of the information in gmtime() and localtime() isn't available > outside of UNIX: daylight-savings-time-flag, timezone. It's overkill. Oh, nonsense. You mean it isn't available from the *kernel* outside of Unix. That doesn't mean it isn't available. In V6 Unix, the kernel knew about neither of these things, yet gmtime and localtime worked fine. (You *did* have to recompile damn near everything if you weren't in the Eastern time zone, so the change to kernel-supplied info was a big improvement, mind you.) In fact, the kernel is almost certainly the wrong place for this information, because it is potentially subject to change on a per-machine and even per-user basis (big timesharing machines not infrequently have customers signed on from several timezones). Just put it in a file. The inability of stupid microcomputer software suppliers to figure this out is irrelevant. -- "There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry