Just what does "portable" mean?

[Rahul Dhesi]

>>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