Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP
Path: utzoo!linus!decvax!harpo!seismo!rlgvax!cvl!umcp-cs!rehmi
From: rehmi@umcp-cs.UUCP
Newsgroups: net.lang
Subject: Re: RE: Re: I/O operations in programming languages
Message-ID: <2358@umcp-cs.UUCP>
Date: Fri, 2-Sep-83 11:56:15 EDT
Article-I.D.: umcp-cs.2358
Posted: Fri Sep  2 11:56:15 1983
Date-Received: Sat, 3-Sep-83 05:48:07 EDT
References: <318@rdin.UUCP>
Organization: Univ. of Maryland, Computer Science Dept.
Lines: 61

From: perl@rdin.UUCP

	You only refer to porting C from UNIX to UNIX.

I should have been clearer - some ports were from C w/Un*x to standalone
C with a library to do unix-like i/o.

	THAT's why the I/O always works.  If you are only concerned with
	porting from UNIX to UNIX, ANY language will port with no I/O
	problems.  It has nothing to do with C.  In fact, C I/O is so
	heavily based on UNIX I/O concepts that it is the HARDEST language
	to port to a DIFFERENT operating system.  I had to use C under CP/M.
	CP/M does not keep track of the size of a file in bytes; only in
	blocks.  If you had to port most UNIX utilities to CP/M, it would be
	nearly impossible.  I had to write my programs to use header records
	to indicate the length of the file since the OS wouldn't do it for me.

But C does not have I/O! Look, under vanilla bsd/bell you have at least
three immediately obvious choices for i/o. The first is directly with system
calls, e.g. read() and write(). The second is with the buffered i/o library,
e.g. fread() and fwrite(). The third is with the stdio library, like scanf()
and printf(). Even the system calls are in a library (the calling sequence).

	I agree that Pascal is not the answer, but whoever it is that
	maintains the C standard doesn't seem to be aware that there's a
	question! Why can't C have dynamically dimensioned arrays, run
	time error messages, array bounds checking, and a few other
	little bits of civilization that every other language since
	FORTRAN has had? I've known people to spend DAYS trying to debug
	a program before they discover that a variable is being passed to
	a function that's expecting a different type.

Because they're slow (in reference to both "Why can't..." and "I've
known..."). Besides, there are often libraries for doing error messages
easy. And what do you think link is for? Decoration? It does a pretty
complete rundown over the code in question, including type checking,
unreferenced variables, etc... There is this library function called
"malloc" which will give you all the space you want, so you can have dynamic
allocation. Array bounds checking is slow. Besides, what is the point of
starting your array at element -5 and running up to 27? It is slow, and adds
to the confusion...

	Just like V'GER, the C standard MUST evolve. It maddens me to
	see people trying to keep C from getting better in the interest
	of standardization. If you want stunted standardization, use
	FORTRAN. Let's let C stand for Civilized.
	
The C standard is spartan yet rich. It is concise and straightforward. You
can ignore the machine it is running on, or write the machine's os in it.
The language itself is a win. The libraries... well, all things must change,
hopefully for the better.

					-rehmi
-- 

By the fork, spoon, and exec of The Basfour.

Arpa:   rehmi.umcp-cs@udel-relay
Uucp:...!harpo!seismo!umcp-cs!rehmi
     ...!{allegra,brl-bmd}!umcp-cs!rehmi