Newsgroups: comp.std.c
Path: utzoo!utgpu!jarvis.csri.toronto.edu!dgp.toronto.edu!flaps
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: Testing Equal Pointers (was: detecting invalid pointers)
Message-ID: <8904041639.AA02825@champlain.dgp.toronto.edu>
Organization: Dynamic Graphics Project, University of Toronto
References: <1989Mar21.085704.15894@ateng.ateng.com> <16039@cup.portal.com> <375@sdti.SDTI.COM> <9930@smoke.BRL.MIL> <1989Mar29.083727.8934@ateng.ateng.com>
Date: Tue, 4 Apr 89 12:39:55 EDT


chip@ateng.ateng.com (Chip Salzenberg) writes:
>After all, if a given algorithm is non-portable and is therefore surrounded
>by "#ifdef MSDOS"/"#endif", why bother trying to make its implementation
>portable?
>
>For an example:  Name a portable way to get the complete shift state of a
>keyboard.  No, wait, that's too hard.  Name a portable way to *express* the
>complete shift state of a keyboard.  Code involving such an entity is non-
>portable from the get-go; so there's no reason to avoid non-portable coding
>in its implementation.

Wellll, it's true that it's not worthwhile to squeeze the last bit of annoying
unportable code out, if there is such a last bit.  However, I believe that most
of the guidelines for portable programming are also good guidelines for robust
programming, and in particular even though something may be intrinsically
ms-dos dependent in might not be ms-dos v3.3.1 dependent, and more portable
programming techniques can make your code more likely to survive an operating
system upgrade.  (Or compiler upgrade (or change), for that matter.)

ajr

--
"The goto statement has been the focus of much of this controversy."
	    -- Aho & Ullman, Principles of Compiler Design, A-W 1977, page 54.