mdf@trwrba.UUCP (Mark D. Falleroni) (01/14/86)
Thiis article is posted in response to inquiries I have received with regards to ST COMM, a program I wrote with the HABA HIPPO C compiler. As posted, and using the HABA HIPPO C compiler, the program comppiles and runs withoout error. If one attempts to compile it using the DRI C compiler provided with the development package, errors will result. I was unaware of this until Alan Kenington wrote me. His analysis seems to make sense: HABA HIPPO C defines an 'int' as a 32 bit quantity. DRI C defines an 'int' as a 16 bit quantity. Alan says that the errors occur with the 'switch (c)' statement; and they are due to the different 'int' representations of the compilers. I hope this helps anyone encountering these errors. It has been a while since I posted the source, and I am not thhat familiar with it anymore. Maybe Alan will read this and repost his analysis for all to digest. Mark Falleroni Ogden Engineering Office TRW Defense Systems Ogden, Utah <mdf>
knnngt@ukma.UUCP (Alan Kennington) (01/15/86)
Actually, the reason I wanted to compile STComm was to use a 1200 baud modem I've got, which is just appalling using ST Talk. Believe it or not, the local store is still selling this garbage. It owrks for xmodem, but everybody but the computer store down the street seems to know that the VT52 aspects don't work on, for instance, vi. And I just wasted $40 on a program called typesetter ST. It now lies on the floor. That's the last time I get pressurised into buying garbage like that. From now on, I reserve the right to walk out of a computer store without buying anything!!! Now my real reason for this note is to expound on my theory about what is wrong with the ST Comm. Well, nothing, except that pass 1 (I think) of the DRI C compiler gives a warning about multiply defined cases. You will see clearly from the following excerpts why. DRI has 16-bit ints, whereas Hippo has 32-bit ints. Hence Hippo thinks F3, F2 etc. are different, and DRI thinks they are all 0. Clearly the solution is to make c a longword. One of the problems with C is that it cannot be machine-independent. If every program refuses to use any larger integer than 65k, then that is resources wasted, but the alternative is non-portability. The real solution is, of course, to use #define WORD short #define LONGWORD double or something similar, and then for different compilers, adjustments can be made at teh beginning of the program. I haven't checked the rest of the program. Nor have I run it with the corrected type for "c". While I'm on the topic of use of the top portion of a longword, someone posted a warning a while ago that use of the top byte of addresses was dangerous because it made the code non-upwardly-compatible with later 68k chips. If the ST is ever going to use a 68020 chip, it's going to need a major overhaul in the OS, because the top byte is used with wild abandon!!! And now this.... #define F10 0x440000 #define F1 0x3B0000 #define F2 0x3C0000 #define F3 0x3D0000 ###### about 150 lines of code ######## put_serial() { unsigned int c; int wait; short go_on,n,st; char name[14]; inv_on(); printf("\n**** F10 = exit to MAIN MENU ****\n"); inv_off(); ctr = 0; st = OFF; wait = 0; cnt = 0; go_on = 1; while (go_on == 1) { while ((n = conis()) < 0) /* GET CHAR INPUT WITHOUT ECHO */ { /* SCREEN */ c = necin(); switch (c) { case F3 : dsave_on(); /* SAVE TO DISK */ break; case F2 : transmit(); /* TRANSMIT FILE */ break; case F1 : psave_on(); /* SAVE FOR PRINTER */ break; case F10: go_on = 0; /* EXIT TO MAIN MENU */ if (psave == ON || dsave == ON) dump(); break; case HELP : help(); break; default : auxout(c); /* OUTPUT TO SERIAL PORT */ } } ###### simply hundreds more lines of code ###### The second, third, fourth and fifth case statements are flagged as multiply defining a switch. This is because they all look like 0 to the compiler. Enough said. Most readers will either find this utterly trivial or incomprehensible. I hope someone out there finds it useful. But the moral of the story, folks, is that you must find some way of assuring either portability or ease of modification. This rotten C language is so painful to read that no one really wants to go through your program to find out how the compiler is going to misinterpret your code. zzzzzzzzzzzzzzzzzzzzzzzzzzzz .............ak. The person who requested me to post this explanation is not responsible for the nonsense therein. zzzzzzzzzzzzzzzzzzzzzzzzzzzzz...............ak.