Path: utzoo!mnetor!uunet!husc6!ut-sally!utah-cs!utah-gr!uplherc!sp7040!obie!wsccs!terry From: terry@wsccs.UUCP (terry) Newsgroups: comp.lang.c Subject: Re: nasty evil pointers Message-ID: <338@wsccs.UUCP> Date: 20 Mar 88 09:57:21 GMT References: <13100003@bucc2> <1159@silver.bacs.indiana.edu> <2315@bsu-cs.UUCP> Lines: 118 Summary: Yeah, so what? In article <2315@bsu-cs.UUCP>, null@bsu-cs.UUCP (Patrick Bennett) writes: } In article <13100003@bucc2> brian@bucc2.UUCP writes: } > } >It would be nice if we could check every pointer as } >it was used... } > } > } >If pointer } >pointed, say, into the operating system or the text space, the function } >would print a message and exit(). Otherwise it would return. Before going further, I would like to point out that the quote above is referring to a language feature, NOT an operating system feature. } OS/2 provides this... Different memory areas can have varying levels of } protection. When this protection is broken, whether by attempting to modify, } read, whatever (depends on the protection) the program is promptly aborted but } with appropriate error info... } } Although I personally don't have or use OS/2 I obtained this information from } the OS/2 Programmer's Guide by Ed Iacobucci (The leader of the IBM OS/2 } Design Team) What I think Brian was saying was a reference to the _kind_ of message he received, not that he didn't receive it. Anyone who's gotten the message 'segmentation fault - core dumped' realizes that he has reached outside his address space. I think the simplist method of determining where the problem occurred would be in adb, since you have the arguments and file header info readily available. If I'm wrong, and Brian was suggesting that the compiler error if you have a pointer pointing into the noplace (and this whould be better resolved by the linker, in that it could be an external pointer), I would have to take exception. This kind of checking would imply that 1) only constant pointers could accurately be checked, or 2) that checking should occur at assignment time. The first of these is inadequate, as constant pointers seldom break, and the second is ridiculous, in that the assignment value would have to be checked at assignment time, leading to a number of problems in type- checking, speed of execution, etc. If one truly felt compelled to _DO_ something about it, you could write grungy code like: extern void *_begincs; /* linker would define these*/ extern void *_endcs; extern void *_beginds; extern void *_endds; void * savemefrommyself( arg) void *arg; { if( arg >= _begincs && arg <= _endcs) return( arg); if( arg >= _beginds && arg <= _endds) return( arg); printf( "Your pointer points to the noplace\n"); exit( 1); } main() { char *p, *q; . . . p = (char *)savemefrommyself( (void *)q); . . . } Personally, I'd prefer it if the compiler didn't automatically write this for me. It also leaves open the problem of "what if it's supposed to point into the data segment and it points into the code segment instead". I admit, that with enough dorking around you could probably kludge something that would make the wrong assumption only 30% of the time, but why? Eventually, you'd end up with it breaking something like func() { char *q; q=(char *)NULL; /* breaks here*/ . . . if( errcond1) q = "Error condition 1"; if( errcond2) q = "Error condition 2"; . . . if( q == (char *)NULL) printf( "Operation complete"); else printf( "Error: %s", q); } Whereas if it were implimented in adb, you could do something like: $ a.out Segmentation fault - core dumped $ adb a.out core _ $C main() xxxxxxxxxxx func() xxxxxxxxxxx zzzzzz yyyyyy address yyyyyy prior to data segment _ Which is much more informative, and prettier, yoo. | Terry Lambert UUCP: ...{ decvax, ihnp4 } | | @ Century Software : ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'There are monkey boys in the facility. Do not be alarmed; you are secure' |