jss@hector.UUCP (Jerry Schwarz) (09/14/88)
In article <8453@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > >No, sorry. It happens to work (accidentally) in many cases on many >implementations, but since it can fail on some and is not guaranteed, >it is not "portable". The above illustrates an unfortunate shift that is occurring in the use of the phrase "portable code". When I use that phrase I mean that IN PRACTICE the code can be run on a large variety of systems. It is not a binary attribute, and it makes sense to say that one version of a routine is more portable than another because it works correctly in more environments. E.g. code that works on all UNIX systems is portable, but code that works on UNIX and DOS systems is more portable. Doug (and others) appear to be using "portable" to mean that the code whose behavior is guaranteed by the ANSI standard. Since the ANSI committee went to the trouble to invent a precise technical phrase, namely "stricly conforming", for this concept I suggest that we use that phrase when that is the intended meaning and continue to use "portable" for the less precise, but very important practical, concept associated with moving code between systems. Even a strictly conforming program may not be portable if the compiler on some important system has a bug or if the code makes an unreasonable assumption about the availability of some resource. And on the other hand, a program that, in Doug's words, "works (accidentally) in many cases on many implementations" can reasonably be described as moderately portable even if it is not strictly conforming. Jerry Schwarz AT&T Bell Labs, Murray Hill
henry@utzoo.uucp (Henry Spencer) (09/17/88)
In article <10595@ulysses.homer.nj.att.com> jss@hector.UUCP (Jerry Schwarz) writes: >The above illustrates an unfortunate shift that is occurring in the >use of the phrase "portable code". When I use that phrase I mean >that IN PRACTICE the code can be run on a large variety of systems. >It is not a binary attribute... >Doug (and others) appear to be using "portable" to mean that the code >whose behavior is guaranteed by the ANSI standard... Yes, we do. The reason for this is that it's not that hard to do. A serious commitment to portability should imply this level of effort; anything much less is sheer laziness. It does require a bit of work, and avoidance of certain items of "VAX chauvinism" like assuming a big linear address space or 32-bit ints. Big deal. We (at least, I think I speak for Doug and others as well as myself) are willing to use "portable" as a non-boolean attribute, e.g. to talk about "levels of portability", but when we use it as a boolean, e.g. "this program is portable", that's what we mean. This is a reasonable and proper usage. (Note that one can run into situations where the characteristics of the problem make true portability impossible, but that is not the same thing as falling short because you can't be bothered.) -- NASA is into artificial | Henry Spencer at U of Toronto Zoology stupidity. - Jerry Pournelle | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
g-rh@cca.CCA.COM (Richard Harter) (09/18/88)
In article <1988Sep16.170408.16304@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <10595@ulysses.homer.nj.att.com> jss@hector.UUCP (Jerry Schwarz) writes: >>The above illustrates an unfortunate shift that is occurring in the >>use of the phrase "portable code". When I use that phrase I mean >>that IN PRACTICE the code can be run on a large variety of systems. >>It is not a binary attribute... >>Doug (and others) appear to be using "portable" to mean that the code >>whose behavior is guaranteed by the ANSI standard... >Yes, we do. The reason for this is that it's not that hard to do. A >serious commitment to portability should imply this level of effort; >anything much less is sheer laziness. It does require a bit of work, >and avoidance of certain items of "VAX chauvinism" like assuming a >big linear address space or 32-bit ints. Big deal. Having dealt (the hard way) with portability issues, I have to agree that portability is, in general, not a binary issue. A program is fully portable if you can port it to all machines having a C compiler without altering the code. It is *very* difficult to do this in programs of any size. There are several classes of problems. There are C compilers that are archaic, idiosyncratic, or just plain broken. A portable program works on these compilers. [The reply, "my program is portable, it's the compiler's fault", doesn't cut the mustard. If you have to port you are going to have to work with what you've got, not with what you think you should have.] There are sundry implementations of the standard (:-)) library routines. There are architectural considerations, and so on. Henry is quite right to point to the assorted slop that comes from assuming that anything that works on the machine I am using now is OK to use anywhere and decry it. However in practice portability is relative to a class of machines and compilers. Maybe some day you will be able to write real portable code that works on all machines, because there is a standard that everyone follows. In the mean time the rule is that you define the portability assumptions that you are going to work within, and you know what restrictions those assumptions imply. *note: In a VMS C port recently we got bitten on the monocase externals gotcha. A nice tool to have would be one that reports all potential identifier problems. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
gwyn@smoke.ARPA (Doug Gwyn ) (09/18/88)
In article <1988Sep16.170408.16304@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: -In article <10595@ulysses.homer.nj.att.com> jss@hector.UUCP (Jerry Schwarz) writes: ->Doug (and others) appear to be using "portable" to mean that the code ->whose behavior is guaranteed by the ANSI standard... -We (at least, I think I speak for Doug and others as well as myself) -are willing to use "portable" as a non-boolean attribute, e.g. to talk -about "levels of portability", but when we use it as a boolean, e.g. -"this program is portable", that's what we mean. This is a reasonable -and proper usage. Actually, I'll usually say "standard conforming" when that is what I intend. To me, portable C programming involves considerably more than merely not violating language specifications; it also means not relying on specific aspects of the implementation that are not nailed down by the spec. (There are many intentionally "implementation defined" areas of the C language.) If one gets in the habit of not relying on system-specific assumptions, it becomes progressively less of an issue. Perhaps a couple of times a year I'll have to make a deliberate decision as to whether to rely on some non-portable assumption (which should ALWAYS be clearly flagged as such), for example relying on the ASCII character codes when converting numeric text strings to internal binary. The rest of the time I don't even need to consider whether it might be worth doing that; it's not appreciably more trouble to use a fully portable method. I like to think my applications will run without change on systems from Apple IIs to Cray-2s (all of which we have around here or at home). Of course usually prevents full attainment of this ideal, but there is no good excuse for not trying.
gwyn@smoke.ARPA (Doug Gwyn ) (09/18/88)
In article <33423@cca.CCA.COM> g-rh@XAIT.Xerox.COM (Richard Harter) writes:
-*note: In a VMS C port recently we got bitten on the monocase externals
-gotcha. A nice tool to have would be one that reports all potential
-identifier problems.
UNIX "lint -p" does this.friedl@vsi.UUCP (Stephen J. Friedl) (09/18/88)
In article <8517@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) writes:
< I like to think my applications will run without change on systems from
< Apple IIs to Cray-2s (all of which we have around here or at home). Of
< course usually prevents full attainment of this ideal, but there is no
< good excuse for not trying.
It is kind of amusing to contemplate that Doug might use an
Apple at work and then go home to play on his Cray :-).
--
Steve Friedl V-Systems, Inc. +1 714 545 6442 3B2-kind-of-guy
friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl
------------Nancy Reagan on conductance: "Just say mho"------------gwyn@smoke.ARPA (Doug Gwyn ) (09/19/88)
In article <843@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes: >It is kind of amusing to contemplate that Doug might use an >Apple at work and then go home to play on his Cray :-). Just don't put me on the spot by asking which I find more useful!
g-rh@cca.CCA.COM (Richard Harter) (09/19/88)
In article <8518@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <33423@cca.CCA.COM> g-rh@XAIT.Xerox.COM (Richard Harter) writes: >-*note: In a VMS C port recently we got bitten on the monocase externals >-gotcha. A nice tool to have would be one that reports all potential >-identifier problems. >UNIX "lint -p" does this. Among other things. I had more in mind something that specifically dealt with identifier problems, i.e. potential case conflicts and identifier length issues with the ability to set ambiguity lengths and maximum lengths as options. It's a trivial matter to set up a program to do this, given a list of all the externals referenced and declared. Maybe you can get the right list from cxref. Come to think on it, I've got a C cross reference program that does this for functions. It would be a simple matter to expand it to put out external variables as well. Never mind. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (09/21/88)
I think people should be very careful to appreciate that standard
conformant is not the same as portable. Use of ANSI constructs such as
volatile, const, and common extensions such as enum will just about
guarantee that someones fairly common compiler will break. I still get
complaints that passing struct by value isn't valid C.
dpANS has a lot of stuff which is missing from most compilers, even
though it may not be the SAME stuff. Header files may be missing or may
be missing pieces, etc.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -meatbowler@watmath.waterloo.edu (Alan T. Bowler [SDG]) (09/30/88)
In article <1988Sep16.170408.16304@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >We (at least, I think I speak for Doug and others as well as myself) >are willing to use "portable" as a non-boolean attribute, e.g. to talk >about "levels of portability", but when we use it as a boolean, e.g. >"this program is portable", that's what we mean. This is a reasonable >and proper usage. At one time there were 2 terms "portable" and "machine independant". All programs were "portable" to some extent. The question of interest was "how portable?" I.e. how much work was it to move (i.e. "port") the program to a new environment. This was useful because you could describe the techique of increasing the portability of a program by dividing the source modules into the machine independant and machine dependant parts. Since you seem to want to redefine "portable" as machine independant, can you us a new term that decribes how hard it is to "port" a program from one environment to another?
gwyn@smoke.ARPA (Doug Gwyn ) (10/03/88)
In article <21199@watmath.waterloo.edu> atbowler@watmath.waterloo.edu (Alan T. Bowler [SDG]) writes: >At one time there were 2 terms "portable" and "machine independant". This appears to be a dispute between holders of the view that a significant application should be divided into machine-specific and machine-independent parts (which, if done properly, makes porting fairly easy) and holders of the view that most significant C applications need not depend on machine specifics in the first place. I think Henry and I are in the latter camp.