Just what does "portable" mean?

[Steve Dempsey]

In article <4412 at bsu-cs.UUCP> dhesi at 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 at longs.LANCE.ColoState.Edu
 \/ _|/ _       _\Computer Asisted Engineering\dempsey at handel.CS.ColoState.Edu
 /\  | (_) | |_(_)\Colorado State University   \...!ncar!handel!dempsey
/_/_/(_/\_/ V   \_ \Fort Collins, CO  80523     \(303)-491-0630