gregb@dowjone.UUCP (Gregory S. Baber) (04/04/89)
Given that portable C code is a desire, how does someone who has only had exposure to one "flavor" of C compiler (cc, gcc, Microsoft C 5.1, etc.) decide whether his or her code is portable, aside from actually trying to compile it on the target machine? How do you recognize code as being portable or not? Are there tests that you can perform on your code to test for portablility? Books on portable C? Gurus willing to look at your code a pass judgement as to its degree of portability? (1/2 :-) Thanks, gregb -- Reply to: Gregory S. Baber Voice: (609) 520-5077 Dow Jones & Co., Inc. UUCP: ..princeton!dowjone!gregb Box 300 or ..uunet!dowjone!gregb Princeton, N.J. 08543-0300 "So long, and thanks for all the fish"
gwyn@smoke.BRL.MIL (Doug Gwyn ) (04/06/89)
In article <439@warlock.UUCP> gregb@dowjone.UUCP (Gregory S. Baber) writes: >Given that portable C code is a desire, how does someone who has only >had exposure to one "flavor" of C compiler (cc, gcc, Microsoft C 5.1, etc.) >decide whether his or her code is portable, aside from actually trying to >compile it on the target machine? How do you recognize code as being >portable or not? Are there tests that you can perform on your code to test >for portablility? Books on portable C? Gurus willing to look at your code >a pass judgement as to its degree of portability? (1/2 :-) Thanks, gregb The most important step when writing the code is to use a standard C language specification, not your particular vendor's C manual, as your reference. Originally that meant K&R (1st Edition) Appendix A, now it is starting to mean the proposed ANSI C standard, for which K&R 2nd Edition is a pretty good guide (so long as you don't have to deal with "internationalization" issues). The idea is to pay attention to what the language reference guarantees about C, and not to use additional knowledge about the particular way C is implemented in your environment. There are several books about portable C programming. Plum Hall Inc. (1 Spruce Av., Cardiff NJ) specializes in this, and Lapin et al. of Rabbit Software wrote another such book for which I've heard favorable reviews. UNIX systems generally provide a "lint" utility that examines your C code for possible portability problems (among other things). If you have access to "lint" you really should learn how to use it.
ejd@caen.engin.umich.edu (Edward J Driscoll) (04/06/89)
I'm not sure what compiler you're going to use, but some of them have the ability to turn off all non-ANSI extensions with the flick of an option somewhere. You can do this in TurboC (a DOS compiler), and I'd imagine many compilers have this sort of option. The TurboC manuals also have a PORTABILITY note in the description of each of the library functions, with things like "compatible with ANSI", "defined in K&R", or "unique to DOS". A friend of mine was recently telling me about a reference book which cross-referenced a list of standard library functions with a list of operating systems which typically support them. I can't remember what the title is off hand, perhaps someone else....? -- Ed Driscoll The University of Michigan ejd@caen.engin.umich.edu
peter@ficc.uu.net (Peter da Silva) (04/06/89)
Send it to comp.sources. I can assure you that you WILL find out exactly what you have done that's unportable. If that's too drastic... try alt.sources. Everyone else does. (1/2 :->) -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.