chris@umcp-cs.UUCP (Chris Torek) (02/10/86)
In article <720@ttrdc.UUCP> levy@ttrdc.UUCP writes: >In article <3032@umcp-cs.UUCP>, chris@umcp-cs.UUCP (Chris Torek) writes: [followed by my sample portable program, namely a simplified reimplementation of `echo'.] > What about a system where it is impossible to give command line > arguments to a program, like the early-stone-age card reading > IBM systems? On such a system an `echo' program is useless, since it always prints a blank line. However, note that my sample program would indeed successfully print a blank line on such a system. > Is C only allowed to run on machines that DO allow command line > arguments? No; but such a system requires severe design constraints which rule out a program like `echo'. Yet that does not make echo unportable. > Would this program just get run with an argc of 0 in the case > of a stone age system? As to that I cannot say, but again, my code will still print a blank line. > As a matter of fact, must a system support both upper and lower > case characters to support C? No. But it would no doubt break quite a bit of code. That code can be considered unportable in that sense; but here I think one must begin to consider just what extremes of portability are worthwhile. Would you say that screen editors should not exist because they are unportable to some machines? I think the real point is that one should write code as portably as possible given the constraints under which that code is to operate. Window systems cannot run on teletypes; bitmapped graphics cannot run on character-oriented CRTs. Yet I can write a portable routine that does bitmapped graphics using the MIT X window system as a base. I claim there is no contradiction here: that portability does not mean that code runs on any machine anywhere; rather, that it is not *unnecessarily* limited. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu