Xref: utzoo comp.lang.c++:13532 comp.lang.c:39361
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!spool.mu.edu!rex!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!ogicse!intelhf!ichips!inews!pima!bhoughto
From: bhoughto@pima.intel.com (Blair P. Houghton)
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: 64 bit architectures and C/C++
Message-ID: <4284@inews.intel.com>
Date: 18 May 91 08:07:48 GMT
References: <168@shasta.Stanford.EDU> <4068@inews.intel.com> <1991May15.190016.21817@philmtl.philips.ca>
Sender: news@inews.intel.com
Organization: Intel Corp, Chandler, AZ
Lines: 48

In article <1991May15.190016.21817@philmtl.philips.ca> ray@philmtl.philips.ca (Ray Dunn) writes:
>In referenced article, bhoughto@pima.intel.com (Blair P. Houghton) writes:
>>If you're compliant, you're portable.
>
>You only know a program is portable *after* you've tested it on another
>system.  How many do that during the initial development cycle?

Well, I do, several times, to the point of working for a while on
one platform, moving to another, testing, working there for a while,
moving to a third, and so on.  It helps to aim for three targets.

>If I wanted to be controversial, I might say that 'C's supposed
>"portability" is a loaded cannon.  Bugs caused by transferring a piece of
>software to another system will continue to exist, even in compliant
>software.  Prior to "portable" 'C', porting problems were *expected*,
>visible, and handled accordingly.

Now they're bugs in the compiler, not just "issues of
implementation."

If you're using any C construct that produces different
behavior on disparate, conforming implementations, then
either one of those implementations is not conforming or
you are not using ANSI C, but rather have used some sort of
extension or relied on some sort of unspecified behavior,
and therefore your program is not compliant.

>Will developers still assume these bugs to be likely, and handle
>verification accordingly, or will they be lulled by "it compiled first
>time" into thinking that the portability issue has been taken into account
>up front, and treat it with less attention than it deserves?

Your question is all but naive.  I still get valid
enhancement requests on code that's several years old,
which means that I failed to design it to suit the needs of
my customer, which means it's buggy.  Routines that have
been compiled and/or run thousands of times in real-world
situations come up wanting.  Nobody sane assumes that
anything is right the first time (though one may determine
that the probability of failure is low enough to make an
immediate release feasible).

				--Blair
				  "I'm going to put all of this
				   on video and hawk it on cable
				   teevee in the middle of the
				   night while wearing pilled
				   polyester and smiling a lot."