throopw@sheol.UUCP (Wayne Throop) (08/29/90)
> From: meissner@osf.org (Michael Meissner) > C programmers are notorious for thinking that all pointers look the > same. I had to put in several options > [..into the DG MV Eclipse C compiler..] to either flag when one type of > pointer was used in the wrong context, or silently add extra > instructions so that programmers who were too lazy to type things > correctly could get their programs to work. And even these heroic efforts would not save the proud, scarce, and noble band of siblings who were trying to port code to this class of machine from those C coders out there who were actively perverse in their faith in the pointerness of pointers. I recall one time when I had employed all the checks that Michael had implemented, and STILL pointers ended up in the wrong format with no warning. Eventually, it was discovered that this particular piece of cr... uh, code deliberately and with malice aforethought declared some pointer externals to be type (struct foo*) in some modules and (char *) in others. (I say we found this "eventually". Lint would have found it immediately, of course, but the original coders had done something-or-other to cloud lint's mind on the matter. Never did get that sucker running on the MV, as I recall, though it consumed many a CPU cycle on Vaxen the world over.) ( If I were to try porting it today, I'd probably take to calling the program "Bo". You know. "Bo knows pointer format." "Bo knows endianness." "Bo knows stack direction." "Bo knows the linker algorithm." "Bo knows int == long." And so on, ad nauseam. ) Like they say, what programers don't know ain't the problem. It's all them things they DO know that jest ain't SO. -- Wayne Throop <backbone>!mcnc!rti!sheol!throopw or sheol!throopw@rti.rti.org
vu0310@bingvaxu.cc.binghamton.edu (R. Kym Horsell) (08/29/90)
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... -Kym Horsell
meissner@osf.org (Michael Meissner) (08/29/90)
In article <3905@bingvaxu.cc.binghamton.edu> vu0310@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@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?