HARRIS FLAME Re: SHORT vs. INT

[Guy Harris]

> FLAME OF MY OWN:
> People such as Mr. Harris should be aware that not all people participating
> in this forum are experts.  The question was a valid one, and deserved a
> reasonable response, not a better-than-thou dissertation.  Such responses
> just intimidate people who might otherwise benefit by asking questions of
> this type.

People who use the C language should be sufficiently expert that they
understand that "long" and "short" should not be selected in favor of "int"
only if they are of different sizes on the machine you're coding on.
Period.  If a C programmer doesn't understand that, then they have not been
adequately trained in the C language and should not use the C language until
they have been so trained.  From the questions put forth in net.lang.c, it's
apparent that the training offered to many C programmers is abysmal.  I'm
not in the business of training C programmers.  I *am*, unfortunately, in
the business of fixing the mistakes made by inexpert C programmers.  I wish
I weren't in that business.  Perhaps there should be separate newsgroups for
novice and expert C users; however, the difference between the level of
expertise exhibited by posters to net.unix and net.unix-wizards has steadily
diminished over time.

In any case, net.lang.c should *not* be forced to serve as a place where
people pick up information that should have been imparted to them when they
learned C but wasn't.  The proper use of "short", "int", and "long" very
definitely falls into "what you should have learned before you started to
use C".  Unfortunately, a look at the number of programs posted to
"net.sources" which have to have "int"s replaced by "long"s before they run
on machines other than the VAX for which they were written indicates that
far too few people *do* learn the proper use of "short", "int", and "long".
If people were as careless at using, say, saws as they were at using the C
programming language, the rate at which people lost fingers in their
workshops would be a national disgrace.  Read some of the postings in the
"net.bugs" groups if you don't believe me.  A *lot* of those bugs are simply
bonehead coding errors; the disgrace is that they come from a system which
is shipped and supported by a Large American Corporation.  I don't know if
other such systems have such a large proportion of bugs caused by stupid
errors like not checking whether a pointer is null before using it (I doubt
that occurs nearly as much on VMS, because VMS does *not* map location zero
into a process' address space), but if they do we have an even bigger
problem.

	Guy Harris