An overview ...

[Charles Hannum]

of some of the current flame wars on comp.lang.c ...


NULL pointers
-------------

How should one deal with the various contexts of NULL pointers in C, and
casting them properly, in order to write portable C programs?

My solution:  Write "NULL", except as arguments to vararg functions, where I
put an explicit cast.  (Actually, when I think about it, I can't ever remember
passing NULL to a vararg function, except for execl().  Just how common is
this?)


How to shut up lint
-------------------

How do you keep lint from complaining about things like the arguments to
malloc()?

My solution:  Don't use lint; it's ancient and brain-dead.  Learn C, or get a C
guru to help you.


To parenthesize, or not to parenthesize?
----------------------------------------
(This actually seems to have ended a little while ago, but I'll cover it
anyway.)

In a lot of cases, C operator precedence sucks.  (I can quote K&R saying the
same thing -- different wording, of course.  Lets not argue about this point.)
How does one deal with it?

My solution:  Most of the time I know.  When I don't, I try it one way, and if
it doesn't work right, I put parentheses in to force the issue.  Many times I
just add them to begin with.  Who cares about a few extra parentheses, when you
can *know* that the code will work as intended?  (I hesitate to put "correctly"
there ... B-))


A faster language (Prolog vs. C)?
---------------------------------

Someone posts an example of a program which appears to be faster in Prolog
than in C, hoping to get the C community upset, and succeeding.

My answer:  The two are not comparable, because:
  1) It's an extremely small subset of each language
  2) The compilers are doing different optimizations, which means inherently
  3) The algorithms are not comparable


Imprecision of floating point numbers
-------------------------------------

This topic has been BEATEN TO DEATH in recent time.  Floating point numbers
simply can't represent every single number in their range perfectly.  It's
impossible without a HUGE precision.

Someone mentioned the problem of converting numbers on input and output.  This
is, in fact, a major problem.  I haven't seen a reference to the cited papers
before, but I will definitely take a look at them.

My solution:  If you want true accuracy, use variable-precision BCD, if you
have the time to wait.


Initializing bit fields
-----------------------

This seems to be well defined in ANSI C.  There shouldn't be any argument about
it here, except of course that, as usual, there is the question of "JUST HOW
THE HELL DO I GET A COPY OF THE ANSI STANDARD?!?"

Also, while the posting saying "... this doesn't even look like C to me ..."
was probably out of place, it *is* very easy to learn to ignore the fluff and
cut down to the information.  The person that did the flaming here should have
reconsidered his posting (and so should the person who flamed him back).

The other people that talked about this treated it seriously, and without
burning a hole through my monitor.  I commend them for that.  [B-)]

My solution:  Read all the follow-ups to the original article.


To beep or not to beep
----------------------

Beeping is an effective way to get a user's attention.  It can also be annoying
though.  Should programs beep or not?

My answer:  I don't see anything wrong with beeping, especially when on most
machines I can control the volume, if not the pitch also.  I don't stay up late
at night 2 feet away from someone who is sleeping, so I'm not worried about the
noise.  It simply doesn't matter to me.  And besides, visual beeps always take
far too much CPU.  And I *despise* long messages like:

WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING
[insert not-so-important error message here]

... when a simple beep would have sufficed and gotten my attention faster, AND
wouldn't have cluttered up my screen as much.




A side note
-----------

I honestly think we should all sit down calmly, take a relaxation pill, and
think things over.  (In case you don't recognize it, that's a paraphrase from
2001: A Space Odyssey.  [My spelling might be off.  It's 3 AM ...])

There have been far too many flame wars in comp.lang.c.  In fact, on most days
I can mark over 3/4 of all the articles without reading them, because I know
they're just a continuation of a flame war.  It's really tiring.



Disclaimer
----------
I'm open to additions and corrections to anything I say, provided it's in a
positive, non-condescending manner.  I'm always willing to learn from someone
who knows more about something than I.  (And I'm sure there are a *lot* of
people here that know C better than I.  I've only been writing it for 9 years.
[B-I]).  However, I abhor it when someone rants and raves, "NO NO NO NO NO!!
GO READ YOUR MANUAL AGAIN!  YOU DON'T KNOW C FOR SH*T!!"
--
 
Virtually,
Charles Martin Hannum		 "Those who say a thing cannot be done should
Please send mail to:		  under no circumstances stand in the way of
hannum at schubert.psu.edu		  he who is doing it." - a misquote