Path: utzoo!mnetor!uunet!husc6!bu-cs!polygen!pablo
From: pablo@polygen.uucp (Pablo Halpern)
Newsgroups: comp.lang.c
Subject: Re: nasty evil pointers
Message-ID: <126@polygen.UUCP>
Date: 14 Mar 88 23:55:32 GMT
References: <13100003@bucc2> <13100004@bucc2>
Reply-To: pablo@polygen.UUCP (Pablo Halpern)
Organization: Polygen Corporation, Waltham, MA
Lines: 52

In article <13100004@bucc2> brian@bucc2.UUCP writes:
>> /* Written  5:10 am  Mar  7, 1988 by bucc2.UUCP!brian in bucc2:comp.lang.c */
...
>> void pointer_validate(p, n, f)
>>   void *p;
>>   int n;
>>   char *f;
>
>  After I posted my earlier note, I thought of a way to make this problem
>somewhat simpler... The follwing macro can be defined:
>
>#define VAL(p)	(pointer_validate((p), __LINE__, __FILE__), (p))
>
>  Then all that needs to be done is to replace a pointer dereferences with
>*VAL(ptr), for example:

Close, but no cigar.  Side effects will kill you.  For example:

	a = *p++;

would be replaced by:

	a = *VAL(p)++;

which would, in turn, be expanded to:

	a = *(pointer_validate((p), __LINE__, __FILE__), (p))++;

This is sematically incorrect, since the comma operator returns an rvalue
which is not a legal operand for the ++ operator.  Also, if the pointer
expression causes potential side effects, as in:

	a = *func();

the side effect will be carried out twice by the macro.  How about the
following declaration for pointer_validate():

void *pointer_validate(p, n, f)
	void *p;
	int n
	char *f;

Where the return value of pointer_validate is p.  This has the problem
that the return type is no longer the same as the type of p and must be
casted.  This requires any filter that inserts the pointer_validate calls
to understand not only C syntax, but symbol table information as well.
Oh, well, keep trying :-(

Pablo Halpern		|	mit-eddie \
Polygen Corp.		|	princeton  \ !polygen!pablo  (UUCP)
200 Fifth Ave.		|	bu-cs      /
Waltham, MA 02254	|	stellar   /