Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!samsung!uakari.primate.wisc.edu!caen!umich!sharkey!amara!mcdaniel
From: mcdaniel@adi.com (Tim McDaniel)
Newsgroups: comp.lang.c
Subject: Re: Portability Issues
Message-ID: <MCDANIEL.91Apr26114620@dolphin.adi.com>
Date: 26 Apr 91 15:46:20 GMT
References: <2573@plx.UUCP> <1991Apr25.205236.21765@odgate.odesta.com>
Sender: news@adi.COM
Organization: Applied Dynamics International, Inc.; Ann Arbor, Michigan, USA
Lines: 92
In-reply-to: mike@odgate.odesta.com's message of 25 Apr 91 20:52:36 GMT

In article <1991Apr25.205236.21765@odgate.odesta.com>
mike@odgate.odesta.com (Mike J. Kelly) writes:

   An excellent book on portability is "Portable C" by Henry Rabinowitz and
   Chaim Schaap.  Prentice-Hall, 1990.

Like HELL it is!  The authors have a basic understanding of C, but
they miss, misrepresent, or state small inaccuracies about a lot of
points.  They also advocate practices that are unsafe in any language.
This book is dangerous, and a waste of $30.  It's far better to use
Andrew Koenig's "C Traps and Pitfalls" and Mark Horton's "Portable C
Programming".

The most glaring problem is section 9.10, "Porting other people's
code".  In its entirety:

   It is possible to post a large program written by others without
   understanding how it works.  At most, you may have to read some
   small sections of code.  Here is a step-by-step procedure that has
   proven effective in porting other people's code.

   1. Look at the makefile(s) for the code and adjust all
   environment-specific settings to fit your environment.

   2. Look at all the #ifs and #ifdefs in the code to make sure the
   flags are defined appropriately for your environment.

   3. Try to make the program.  Often, it will fail to compile.  Make
   the changes necessary to get it to compile and link.

   4. Lint the code.  Lint all the source files together if possible.
   Make appropriate changes in the code.

   5. Make the program again.

   6. Run the program.  If it dies, use a runtime checker for
   diagnosis, or as a last resort, use a debugger.  Repair the
   program, return to step 3, and repeat.

How do you even START to criticize that?!?

Another example, from page 7: They identify the problem with not
declaring strcat() in:
   
   #define VERSION "1.03"
   void prVersion();
   main()
   {
      prVersion();
      ...
   }
   
   void prVersion()
   {
      static char outmsg[20] = "Version #";
      printf(strcat(outmsg, VERSION));
   }

Hint: what goes wrong when you change the #define to one of these?
   #define VERSION "1.04 alpha (internal)"
   #define VERSION "90% of V2"

They advocate using both new-style and old-style function declarations
in header files (under __STDC__), but only old-style in functions.
The problem of default argument promotions is mentioned ONLY in a
too-brief footnote three pages later.

Floating-point zero should not be used in a Boolean context,
but one of the reasons is NOT that "floating-point zero may not be
all-bits zero in some environments"!

Their five pages on internationalization can't even scratch the
surface.  (This section was right after the "porting procedure" above;
perhaps the authors just got tired when writing that.)

page 140: "The only integer value than can be portably assigned to any
pointer is 0."  Wrong: only an integer constant expression evaluating
to 0 can be assigned.
   int i = 0;
   int *ip = i;
doesn't work.  In general, they don't seem to have a 100%
understanding of pointers and arrays -- but then again, they probably
haven't read Chris Torek.

Bascially, just use Koenig and Horton, and read everything that torek,
gwyn, scs, or ok post.  (I know I'm forgetting a few in that list ...)

--
   "Of course he has a knife; he always has a knife.  We all have knives.
   It's 1183 and we're barbarians."
Tim McDaniel                 Applied Dynamics Int'l.; Ann Arbor, Michigan, USA
Internet: mcdaniel@adi.com                UUCP: {uunet,sharkey}!amara!mcdaniel