On Mon, Jan 21, 2002 at 11:13:33AM +0000, James Fidell wrote:
> Quoting John Marshall:
>> people write non-portable code because they Just Don't Get It.
>
> In what way do they "Just Don't Get It"?
Some people seem not to understand *why* they ought to be writing
portable code. They think "this code is only for Palm OS, so I don't
have to worry about portability".
They forget that portability also means between different compilers on
one platform like Palm OS, and even between different versions of the
same compiler on one platform.
Such people write code now and claim that "it works" when it happens to
do what they want with the current version of their current compiler on
their current platform. People writing what I call portable code know
(or more to the point, *care about*) what is guaranteed by the language
and what is merely an artifact of what their current version/compiler/
platform will let them get away with, and code accordingly.
The latter people are insulated from fallout from optimisation
improvements and the like in new versions of their tools. Their code
continues to work.
The former people's code mysteriously fails when they upgrade their
tools or move to a different toolchain, and they mistakenly feel
betrayed by their tools vendor (and probably write whiney emails).
The canonical example of optimisation fallout with non-portable code is
-fstrict-aliasing; see for example the whining in the flame war around
http://gcc.gnu.org/ml/gcc/1999-06n/msg00236.html
The canonical example for us of "my code is so non-portable it doesn't
even work on the platform I wrote it for" is probably this "no matter
how hard I try to assign it to a UInt32, ints are still ints" problem,
and I tried to make my previous posting a useful one to point people to
the next ten times this comes up on palm-dev-forum. Also (as I told the
original poster two weeks ago :-)) it's covered in the C FAQ.
On Mon, Jan 21, 2002 at 04:59:06PM +0000, James Fidell wrote:
>Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
>> Something like depending on NULL being all-bits-zero .. like in:
>>
>> if (!something)
>> do_something_else();
[...]
>> if (something==NULL)
>> do_something_else();
Nope. I expected I'd regret that example :-). NULL is by definition 0,
so these two are equivalent. But a null pointer might not be all-bits-
zero, so what I had in mind was that "memset (&struct1, 0, sizeof struct1)"
does zero any integer fields, but does not portably set any pointer
fields to NULL.
> So, I guess we need to seek enlightenment elsewhere.
I hear much enlightenment is to be found in the C FAQ.
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
