Path: utzoo!attcan!uunet!husc6!cs.utexas.edu!steveb
From: steveb@cs.utexas.edu (Steve Benz)
Newsgroups: comp.arch
Subject: Re: Semantics (was Software Distribution)
Message-ID: <3481@cs.utexas.edu>
Date: 6 Oct 88 15:41:43 GMT
References: <634@eiger.iis.UUCP> <993@esunix.UUCP> <13889@mimsy.UUCP>
Sender: news@cs.utexas.edu
Organization: U. Texas CS Dept., Austin, Texas
Lines: 32

In article <13889@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>In article <993@esunix.UUCP> bpendlet@esunix.UUCP (Bob Pendleton) writes:
>...
>>Since NULL can be stored in a pointer, the actions of all pointer
>>operators when applied to NULL should, in my opinion, be defined.
>...
>It is up to the programmer, and the buyer of programs, to make sure
>that programs in this language do not depend on undefined semantics.

First off -- not all operations *can* be "defined" -- for instance,
square root of a real number cannot be defined over all real numbers.
But that's mostly due to the definition of "define" which seems
to be in vogue in this discussion.  In fact, square root of a negative
number is defined -- to an error.

The difficulty here is that not all systems recover or recognize errors
in the same way.

HOWEVER!  That should not be considered a factor in this discussion.
Vendors that sell software with semantic errors are selling software
with bugs.

Requiring every machine to detect and recover from semantic errors in
the same way only helps in that bugs will have the same symptoms on
every machine.

I would simply recommend that when vendors test their software, they
turn on compiler switches which enable strict semantic checking
(i.e. turn on stray pointer checking, index checking, 0-divide checking,
negative root checking....)

				- Steve Benz