Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!usc!ucsd!ucsdhub!celit!ps
From: ps@fps.com (Patricia Shanahan)
Newsgroups: comp.std.c
Subject: Re: doubtful assumptions about pointers
Message-ID: <6203@celit.fps.com>
Date: 16 Jan 90 18:01:07 GMT
References: <1250.25ab3338@csc.anu.oz> <11922@smoke.BRL.MIL> <1259.25ae2019@csc.anu.oz> <11954@smoke.BRL.MIL>
Sender: daemon@fps.com
Reply-To: ps@fps.com (Patricia Shanahan)
Organization: FPS Computing Inc., San Diego CA
Lines: 56

In article <11954@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>In article <1259.25ae2019@csc.anu.oz> bdm659@csc.anu.oz writes:
>My notion of a perverse implementation is one that deliberately
>exploits an ambiguity in the specification, with considerably more
>effort than would be required to implement "reasonable" behavior
>such as would be expected by experienced C programmers, to force
>portable programs to use complex code to avoid triggering the
>perverse behavior.  If someone else thinks such an implementation
>should be deemed reasonable, he's disconnected from the real world
>of computer programming.
>
>This does not include reasonable implementation choices that are
>forced by the architecture or environment, just those for which
>there is no good reason.
>

The first significant C programming job I ever did was a re-targeting of the
portable C compiler to an unusual architecture. Although I was an experienced
programmer, had read K&R (which was the only standard at the time) and had
written a couple of small C programs, I was not an "experienced C programmer".

I really needed a clear standard that did not depend on the concept of 
"reasonable" behavior. If you are going to depend on unwritten background data
to interpret the standard, you don't really need the standard. A good 
standard should permit a skilled programmer to write a correct implementation
without having access to an unwritten code of "reasonable" behavior.

I solved the problem by treating the actual behavior of pcc as a de facto 
standard. Unfortunately, this gave me some problems in the area of mixed type
assignment-ops where the actual behavior of pcc and the statements in K&R
conflicted.

Although I had no intention of being perverse, there were situations in which
K&R appeared to permit behavior that in practice was dangerous. For example,
the natural way of representing a pointer to function was with a half-word
(rather than byte) address. All the jump commands that would be used in calls
required half-word addresses. I set up a perfectly consistent system, in which
conversion between a pointer to function and (for example) an integer involved
one bit shifts. It suited the architecture well and conformed to every rule
about pointer types and conversions that I could find in K&R. Then I found
out some of the details of the signal interface. 

This is really a plea for making sure that the standard actually says 
EVERYTHING that "experienced C programmers" are going to be justified in
expecting of a C implementation, and does not depend on the implementor already
knowing what is expected. I do not think you can assume someone is disconnected
from the real world of computer programming just because they cannot read
the collective minds of all experienced C programmers to find out what is
really required in a C implementation, especially since I have seen it amply
demonstrated that experienced C programmers often disagree about what is 
reasonable.
--
	Patricia Shanahan
	ps@fps.com
        uucp : {decvax!ucbvax || ihnp4 || philabs}!ucsd!celerity!ps
	phone: (619) 271-9940