pointers is pointers (a cautionary tale)

[Michael Meissner]

In article <3905 at bingvaxu.cc.binghamton.edu>
vu0310 at bingvaxu.cc.binghamton.edu (R. Kym Horsell) writes:

| I once (and, luckily, only one) had to convert a large C program
| from something that ran fairly well on a VAX to a DG MV 20000 (*not*
| a 2000). Without a handy-dandy document at hand I quickly found
| a mysterious problem with (char *) vs other pointers -- the
| program tended to consequently bomb at the drop of a hat.
| 
| Solution -- get the thing to work in TURBOC (VAX C didn't have
| prototyping at that time -- under Eunice (Ultrix was not
| available to me at that time)) with prototypes for *every*
| procedure in the whole program. A little lex job was ideal
| for finding all the appropriate headers (ctags didn't find
| all the parameter defs) and assembling them into, as I recall,
| a rather large header file that was subsequently included in
| all relevant C sources.
| 
| Still under TURBO all appropriate pointer problems were found
| and appropriate casts installed (too bad this couldn't be
| easily done in Lex too -- there were *quite* a few of these
| guys).
| 
| The program was then moved back to the 20000 and voila! No problems!
| 
| The move from VAX -> 20000 was worth it as well; the program
| ran about 10 times faster...

I did notice that except for programs calling qsort, if there was a
lint rule in the Makefile, the program usually worked on the MV, since
the effort it takes to make lint shut up, generally results in more
portable programs.  In case you are wondering about qsort, the general
way to deal with lint on qsort, was to cast the data address to be a
char *, but no similar casts were done on the pointers received by the
comparison function, and since it was passed as an address, lint
didn't check the arguments...
--
Michael Meissner	email: meissner at osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

Do apple growers tell their kids money doesn't grow on bushes?