🚀 go-pugleaf

In article <6203@celit.fps.com>, ps@fps.com (Patricia Shanahan) writes:
> [...]
> 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.
>
> [...]
> 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.

I would also note that I wish to be able to write C programs which will be
portable well into the future (at least until the next C standard, or until
we blow up, irradiate, poison, asphyxiate, freeze, or cook ourselves
--- whichever comes first).  Being able to read the minds of all existing C
programmers, and being an expert on all existing hardware, is insufficient to
be sure of what the boundary between "reasonable assumption" and "doubtful
assumption" will be in, say, 1997.  That is one reason why it is worth knowing
what the True Assumptions are, and programming within them.  Fortunately,
this isn't all that difficult in the great majority of cases.

Brendan McKay.   bdm@anucsd.oz.au  or  bdm659@csc1.anu.oz.au