Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!mit-eddie!genrad!decvax!decwrl!sun!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: comp.lang.c
Subject: Re: C Review
Message-ID: <1667@hoptoad.uucp>
Date: Fri, 16-Jan-87 06:14:00 EST
Article-I.D.: hoptoad.1667
Posted: Fri Jan 16 06:14:00 1987
Date-Received: Sat, 17-Jan-87 04:05:25 EST
References: <2313@brl-adm.ARPA>
Organization: Nebula Consultants in San Francisco
Lines: 61
Summary: You guys haven't read much code written on the ST/Mac/Amiga...

The reviewer has probably been reading C code written by graduates from
the 8088 assembler school of engineering.  I hope I'm not the only one
who noticed the really *low* quality of public domain software written
in C on (non-Unix) micros.  (Code first written on Xenix tends to look
that bad too; probably it's written by the same 9 year old kids.)  Of
course as the code ports around it mostly gets cleaner (as it loses
characters from the comments while traveling over lossy serial lines)
but it almost never compares with code written on Unix systems by
people who are paid well to do it well -- like most of us.

It's taken about 6 months to get a version of "arc" (written in C for
msdos) to run semi-reliably on machines with different byte order,
different order of execution, or different word sizes than the 8088.

> "... 95% of all C programmers couldn't give you a good
> explanation of the term lvalue..."
> "... 99%  of  all  professional C  programmers  have no idea
> what typedef is all about, couldn't care less and probably
> won't ever need it."
> "... 99%  of  all  professional C  programmers  have no idea
> what the comma operator is all about, couldn't care less and
> probably won't ever need it."
> "... a C programmer never needs to know what a byte is..."

If you leave the word "professional" out of the above, I would agree.

It gets demonstrated about once a month in this newsgroup just how
little lvalues are understood.  I don't think I've ever coded a typedef
definition -- and just because you can write caddr_t foo; doesn't mean
you know how or why it works.  Most of the uses people put comma to are
confusing to read, like the "old standard" for-loop where you have to
squint the commas from the semicolons.

It's absolutely true that a good C programmer doesn't ever need to know
about bytes.  I might (at 3AM) go so far as to say that a place in a C
program that "knows" about bytes is a portability bug waiting to
happen.  Ask a PDP-10 C hacker, on a machine where copying all the
bytes doesn't necessarily copy all the bits.  One of the posters on
this review said "A good understanding of bytes is essential in writing
portable C programs" or words to that effect.  I'll admit I understand
bytes, but I think this makes me a *worse* C programmer, because I make
unportable assumptions based on my understanding of how my local
machine actually implements C constructs.

> "... Leave the comma operator altogether. An intro book is no
> place for obscure and unmaintainable tricks..."

While most people will never use some parts of the language, a textbook
should document it all, in case you run across it in other peoples' code.

> "... Switch/case could be classified as rarely used and should be
> kept till later.
> "... very few C programmers know much about sizeof..."
> "... Pointers to functions ... few C programmers understand
> them or would ever need them..."

These are off base, though it was news to me that sizeof worked on arbitrary
expressions.
-- 
John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   gnu@ingres.berkeley.edu
/* No comment */