Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!rdin!perl
From: perl@rdin.UUCP (Robert Perlberg)
Newsgroups: net.lang
Subject: RE: Re: I/O operations in programming languages
Message-ID: <315@rdin.UUCP>
Date: Wed, 31-Aug-83 15:53:06 EDT
Article-I.D.: rdin.315
Posted: Wed Aug 31 15:53:06 1983
Date-Received: Thu, 1-Sep-83 00:57:25 EDT
Lines: 58

cFbr*w
In response to umcp-cs!rehmi's article on C portability, you  are
missing  one  very  important point.  You only refer to porting C
from UNIX to UNIX.  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
perhaps 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.

I partly agree with your first statement:

"Don't you *dare* mention C withing ten words of Pascal, Ada,  or
any other such structured, verbose crocks."

Take out the word "crocks" and I couldn't agree  more.   C  isn't
worthy  of  being  associated  with  languages  that  were  truly
designed for portability and logical correctness.

With regard to portability being proportional to one's  knowledge
of  the  machine,  you're right; but in the wrong direction.  The
more you know about the differences between  machines,  the  more
careful  you  will be about exploiting a non-portable feature.  I
am constantly having to patch up code submitted by hackers who do
whatever  seems  to  work  on  their  machine  because they don't
understand that you can't pass just any old variable  type  to  a
function.

And as far as C being hairy and unreadable, that depends  on  how
you code.  Most C code I see outside my company looks like it was
written by a first year BASIC hacker.  There's no law  that  says
that  you have to fit as many functions into one statement as the
compiler can (or often can't) deal with.

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.

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.

Are you listening, Dennis?

Robert Perlberg
Resource Dynamics Inc.
New York
philabs!rdin!perl