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. ; ; ;