[comp.lang.c] Possible extension to C??

nevin1@ihlpf.ATT.COM (00704A-Liber) (01/09/88)

I have a proposal for a extension to C WHICH DOES NOT BREAK EXISTING CODE.

I feel that *0 should be equal to 0 (at least for the data types char, short,
int, long and 'pointer').

Much of the code that I have seen explicitly checks for a NULL pointer and then
performs the same action that would have been performed if the value it pointed
to were 0.

Comments??
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				"The secret compartment of my ring I fill
 /  / _ , __o  ____		 with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah

gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/09/88)

In article <3306@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704A-Liber,N.) writes:
>I feel that *0 should be equal to 0 (at least for the data types char, short,
>int, long and 'pointer').

I think this is totally unworkable.  0 is an int, not a pointer,
so you cannot meanigfully dereference it.  Even a (void *)0 null
pointer cannot meaningfully be said to point to something when
dereferenced.  And what sized 0 would you have the result be?

We've just about gotton all the old VAX BSD null pointer
dereferencing (which, usually inadvertently, capitalized on an
accidental characteristic of the particular implementation)
stamped out.  Let's not backslide now.

ark@alice.UUCP (01/10/88)

In article <3306@ihlpf.ATT.COM>, nevin1@ihlpf.UUCP writes:
> I feel that *0 should be equal to 0 (at least for the data types char, short,
> int, long and 'pointer').

This is very difficult to implement efficiently on some machines.
Consider, for instance, a machine whose operating system forces
location 0 to contain a non-zero value.

rwa@auvax.UUCP (Ross Alexander) (01/11/88)

In article <3306@ihlpf.ATT.COM>, nevin1@ihlpf.UUCP writes:
> I feel that *0 should be equal to 0 (at least for the data types char, short,
> int, long and 'pointer').

I feel the value of *0 ought to be SIGBUS :-) `All the world is _not_ a VAX!'
If you are too lazy to test the lvalue, why should I expect you to test
the rvalue ?

Ross Alexander, Athabasca University
alberta!auvax!rwa

jas@llama.rtech.UUCP (Jim Shankland) (01/11/88)

In article <7010@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <3306@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704A-Liber,N.) writes:
>>I feel that *0 should be equal to 0 (at least for the data types char, short,
>>int, long and 'pointer').
>
>I think this is totally unworkable.... [Followed by several reasoned
>arguments.]

I agree completely, except that I would say something less charitable
than "totally unworkable."  Code that dereferences 0 is buggy.  If I
write such buggy code, I want to hear about it immediately by getting
an access violation when I do the dereference.  I DON'T want my application
to continue running, possibly doing horrible things, because the language
implementor tried to do me a favor by covering up my bug.


Jim Shankland
 ..!ihnp4!cpsc6a!\
              sun!rtech!jas
.!ucbvax!mtxinu!/

rcvie@tuvie (ELIN Forsch.z.) (01/11/88)

To force a program to handle *0 as 0 will break code! There are a lot of
processors where *0 is a meaningful address. When using Intel's 8086 e.g.
*0 is the address of an interrupt vector whose change may be very very
meaningful especially to an o.s. programmer. Therefore the implicit change
of *0 to 0 is a rather bad habbit of some C compilers.

			Dipl.Ing. Dietmar Weickert
			ALCATEL-ELIN Research Center, Vienna, Austria.

al@gtx.com (0732) (01/12/88)

In article <3306@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704A-Liber,N.) writes:
>I have a proposal for a extension to C WHICH DOES NOT BREAK EXISTING CODE.
>
>I feel that *0 should be equal to 0 (at least for the data types char, short,
>int, long and 'pointer').
>

[I assume you really mean *x where x is a NULL pointer]

Run-time checking is contrary to the spirit and original design goals
of C (which were, if I recall some of the early scripture
correctly, that it be [1] not assembly language and [2] as fast as
possible.)

However, I think it would be great if more compilers offered a switch
to turn on as much run-time checking as possible.  Besides the null
pointer deref, one heuristic for catching some bad references
would be to look for (syntactic) occurrences of x[<exp>] where x is the
name of an array and insert code to check whether <exp> exceeds the
dimensioned bound.

This would help the re-tread Fortran programmers who write in the
traditional array[subscript] style, but would not help REAL C
programmers who write *(x + <exp>) or those who contrariwise prefer
(<exp>)[x] or those who just use pointers (not arrays) for everything.
It would just be a heuristic whose usefulness depends on your
programming style.

Doen anyone make a "run-time lint" compiler (short of an interpreter)
to put in checks for things like this?

    ----------------------------------------------------------------------
   | Alan Filipski, GTX Corp, 2501 W. Dunlap, Phoenix, Arizona 85021, USA |
   | {ihnp4,cbosgd,decvax,hplabs,seismo}!sun!sunburn!gtx!al (602)870-1696 |
    ----------------------------------------------------------------------

nevin1@ihlpf.ATT.COM (00704A-Liber) (01/12/88)

In article <3306@ihlpf.ATT.COM>, I write:
> I feel that *0 should be equal to 0 (at least for the data types char, short,
> int, long and 'pointer').

While driving home, I realized that this probably wouldn't even work on my XT
clone, let alone other systems.  (I haven't had to program in assembler for a
LONG time; I forgot that interrupts and bootstraps are sometimes found in low
memory.)  Sorry to waste the bandwidth, and thanks to all the people who
responded with messages and e-mail.

Embarassed,
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				"The secret compartment of my ring I fill
 /  / _ , __o  ____		 with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah

aglew@ccvaxa.UUCP (01/13/88)

>I feel the value of *0 ought to be SIGBUS :-) `All the world is _not_ a VAX!'
>
>Ross Alexander, Athabasca University
>alberta!auvax!rwa

Which should it be, SIGBUS or SIGSEGV?

My POSIX Std 1003.1 - Draft 11, which is quite a bit out of date,
has SIGSEGV in the list of required signals, 3.3.1.2 p 57, but not SIGBUS,
although SIGBUS is mentioned on p 220 in B.3.3.1.1.

SIGSEGV is described as detection of an invalid memory reference.
Seems to me that SIGSEGV is the appropriate thing to provide for access
to a location that you are not permitted to access, as well as access
to a location that you might be permitted to access, but which you haven't
allocated.


Andy "Krazy" Glew. Gould CSD-Urbana.    1101 E. University, Urbana, IL 61801   
    aglew@gould.com     	- preferred, if you have nameserver
    aglew@gswd-vms.gould.com    - if you don't
    aglew@gswd-vms.arpa 	- if you use DoD hosttable
    aglew%mycroft@gswd-vms.arpa - domains are supposed to make things easier?
   
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.

jay@splut.UUCP (Jay Maynard) (01/16/88)

In article <3306@ihlpf.ATT.COM>, nevin1@ihlpf.UUCP writes:
> I feel that *0 should be equal to 0 (at least for the data types char, short,
> int, long and 'pointer').

for (i = 0; i < 100; i++) {
	repeat_after_me('All the world is not a VAX (thankfully).');
	}

This gives me more headaches porting things to my AT than any other issue
(even the 64K max object size).

-- 
Jay Maynard, K5ZC (@WB5BBW)...>splut!< | GEnie: JAYMAYNARD  CI$: 71036,1603
uucp: {uunet!nuchat,academ!uhnix1,{ihnp4,bellcore,killer}!tness1}!splut!jay
Never ascribe to malice that which can adequately be explained by stupidity.
The opinions herein are shared by none of my cats, much less anyone else.

rwa@auvax.UUCP (Ross Alexander) (01/18/88)

In article <28700023@ccvaxa>, aglew@ccvaxa.UUCP writes:
> Which should it be, SIGBUS or SIGSEGV?

What I was really driving at was that `(<arb-type-but-not-void> *) 0'
is a perfectly OK lvalue but shouldn't be expected to have an rvalue
on an arbitrary implementation.  In fact, I think (as a general rule)
that references to the rvalue `*0' should be considered logic errors.

Some previous comments ( re plugging interrupt vectors and so on )
demonstrate a need to handle `*0' from time to time, but I certainly
would like the default behaviour to be a signal of some flavour; if
SIGSEGV is posix-conformant, then SIGSEGV is fine by me.  After all,
if you have anything like a decent memory managment facility, this
check is free ( even an Atari ST can generate the SIG, for crying
out loud ), and there are few enough run-time rationality checks in C
as things stand :-) 

Possibly an implementation could control the signal-generation via an
ioctl() on /dev/mem or some such kluge, if there was a real need to
get at *0.  I don't want to tie anyone's hands (`the programmer is
always right' shall be the whole of the law :-).

Pardon me if all this speculation and handwaving is prior art...

--
Ross Alexander, Athabasca University,
alberta!auvax!rwa

firth@sei.cmu.edu (Robert Firth) (01/19/88)

In article <333@splut.UUCP> jay@splut.UUCP (Jay Maynard) writes:
>In article <3306@ihlpf.ATT.COM>, nevin1@ihlpf.UUCP writes:
>> I feel that *0 should be equal to 0 (at least for the data types char, short,
>> int, long and 'pointer').
>
>for (i = 0; i < 100; i++) {
>	repeat_after_me('All the world is not a VAX (thankfully).');
>	}
>
>This gives me more headaches porting things to my AT than any other issue
>(even the 64K max object size).

Hey, Jay, not so fast there!

The REAL Vax, that is, Vax+VMS, does absolutely the right thing here.  It
maps data page zero out of virtual memory so that almost all attempts
to dereference a null pointer crash at once.

If you must pillory in public the people who tried to make *0 = 0, I will
line up right behind you with an armful of dead cats.  But please make sure
you have the right people.

;
;
;