dhesi@bsu-cs.UUCP (Rahul Dhesi) (10/20/88)
>>I've worked on alot of machines where you cannot do ANY [structures in >>assignment, as parameters and as function return values].... >>Maybe that's not "right". Maybe one should boycott such compilers. Any >>way you look at it though it's still not portable. > >This is a personal decision. Do you pander to every broken compiler? Or >do you concentrate on making the best code that will be accepted by any >correct compiler? This brings us to an important question. When you write "portable" code, just what do you mean? Occasionally, somebody in this newsgroup will say "That's not portable!" when he really means "That's not draft-ANSI conformant!". Right now, one of the best ways of writing NONPORTABLE code is to strictly adhere to the draft-ANSI standard and liberally use features guaranteed by it. Instead of asking whether some C code is "portable", ask if it is "portable enough". To the best of my knowledge, there is no known way of writing truly portable code in general. No matter what you do -- stick to K&R, or stick to draft-ANSI, or stick to your own supposedly portable subset -- you will sooner-or-later encounter a C compiler that won't work with your code. It could be the failure to allow a macro that is big enough, or failure to support something like unsigned char or unsigned long, or failure to support arrays larger than a certain size, or something equally "wrong". Your best bet is to (a) identify the target audience, and (b) pander to the whims and fancies of its C compilers. Then you are "portable enough", and that is what really matters. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
dempsey@handel.colostate.edu. (Steve Dempsey) (10/22/88)
In article <4412@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >>>I've worked on alot of machines where you cannot do ANY [structures in >>>assignment, as parameters and as function return values].... >>>Maybe that's not "right". Maybe one should boycott such compilers. Any >>>way you look at it though it's still not portable. >> >>This is a personal decision. Do you pander to every broken compiler? Or No. Better to fix the compiler once and for all than to write bad code. This is usually easier said than done. >>do you concentrate on making the best code that will be accepted by any >>correct compiler? Well, sort of. I try to stay away from the sticky things that are avoidable, and at least document it otherwise when I think it might break on a different compiler >This brings us to an important question. When you write "portable" >code, just what do you mean? Not relying on known system dependencies and providing an alternative for when the code moves elsewhere. This often means the additional effort of duplicating an existing library in order to bring it along to an environment where it is not available. Pure busy work, I know. >Occasionally, somebody in this newsgroup will say "That's not portable!" >when he really means "That's not draft-ANSI conformant!". Right now, >one of the best ways of writing NONPORTABLE code is to strictly adhere >to the draft-ANSI standard and liberally use features guaranteed by >it. I am most often prompted to exclaim "NP!" when I see something which is absolutely system-dependent, i.e. some system call available in kernel X that is guaranteed not to exist *anywhere* else. >Instead of asking whether some C code is "portable", ask if it is >"portable enough". To the best of my knowledge, there is no known way >of writing truly portable code in general. No matter what you do -- >stick to K&R, or stick to draft-ANSI, or stick to your own supposedly >portable subset -- you will sooner-or-later encounter a C compiler that >won't work with your code. It could be the failure to allow a macro >that is big enough, or failure to support something like unsigned char >or unsigned long, or failure to support arrays larger than a certain >size, or something equally "wrong". But how does one quantify 'enough'? Oh yeah, Enough is enough. :-) I believe sticking K& or draft-ANSI is reasonable. The blame then falls on the weirdo (broken) compiler that behaves differently. Compiler serves programmer, not vice-versa. But again, from the realist point of view, this is not usually practical and you end up pandering to the compiler. With enough complaints about oddities in the compiler, perhaps some of the poorer ones will be repaired. >Your best bet is to (a) identify the target audience, and (b) pander to >the whims and fancies of its C compilers. Then you are "portable >enough", and that is what really matters. Aye, there's the rub: knowing your future audience. I do agree, however. The best you can do is plan for where you know the code is going, and guess at where it will go later. When it comes time to port the code, you will have the assurance that such a port was considered and perhaps a few of the less portable features may be quickly identified and dealt with. >-- >Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi /\ \Steve Dempsey, Center For \steved@longs.LANCE.ColoState.Edu \/ _|/ _ _\Computer Asisted Engineering\dempsey@handel.CS.ColoState.Edu /\ | (_) | |_(_)\Colorado State University \...!ncar!handel!dempsey /_/_/(_/\_/ V \_ \Fort Collins, CO 80523 \(303)-491-0630
gwyn@smoke.BRL.MIL (Doug Gwyn ) (10/23/88)
In article <4412@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >Your best bet is to (a) identify the target audience, and (b) pander to >the whims and fancies of its C compilers. Then you are "portable >enough", and that is what really matters. (a) is not practical. Nearly every large chunk of C code I've seen that is more that a few years old is now running on systems that were unanticpated when it was written. The point of the C Standard is to serve as a "treaty point" between C programmers and C compiler vendors. Obviously it is too soon to expect ANSI C conformance (there isn't even an ANSI C standard yet). The only de facto C standards to this point have been K&R 1st Edition and the AT&T UNIX PCC implementation. One thing that programmers concerned about portability should do is make every effort to confine their use of language features to the common intersection of the de facto standards and the forthcoming official standard. (Prototypes are so useful that some of us recommend coding for both old and new styles of function declaration, using #if __STDC__ conditionals. This can also be used to configure the right standard header inclusions.) There is of course much more to portability than merely following language rules, but if you DON'T follow the rules your code will DEFINITELY be non-portable.