nasty evil pointers

terry terry at wsccs.UUCP
Sun Mar 20 19:57:21 AEST 1988


In article <2315 at bsu-cs.UUCP>, null at bsu-cs.UUCP (Patrick Bennett) writes:
} In article <13100003 at bucc2> brian at 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' |



More information about the Comp.lang.c mailing list