[fpc-pascal] IE 200307043

[Frank Peelo]

Prince Riley wrote:
> Hello Frank,
> 
> If my past post was unclear as  to whether I think the constant 'nil' 
> is  an address, then let me be clear. I quoted the Borland Object 
> Pascal's statement nil 'does not reference anything' I was not equating 
> it to a zero address value. While a pointer with a 'zero' address value 
> should be invalid, it is different from a pointer with a value of 'nil.' 

Agreement.

...
> The distinction between a valid address expression that has 'nil' as an 
> operand and an invalid one (decrementing or shifting a pointer outside a 
> valid address range) however raises a related by seperate issue. FP must 
> have operators like assignment or comparision that allow 'nil' to be 
> used in an expression.

Assignment and comparison, yes. But arithmetic expressions such as nil+1 
do not make sense; if the compiler allows them, that must be by accident.

> The second case is what FP does when nil is used in an expression .  The 
> ultimate problem lies in the first case, how to implement nil in a 
> consistent and reliable way as a internal binary value.

Yes. The compiler makers can choose any value that does not represent 
valid usable memory.

> In K&R, for example, the NULL address pointer is 'defined' but is 
> implemented in several different ways based on target CPU. If you look 
> at C program startup library code you'll see that. The NULL address 
> value in 'C' was defined for several years a binary '0' on VAX, and PDP 
> machines. This allowed tests for invalid or empty pointers using the 
> compact syntatic expression ' if (p) {...}' 

That is still done. In fact, in C++, 0 is a valid representation for the 
NULL value; if the internal representation of NULL is not 0, the 
compiler or library has to fake it.

But FPC is not C++.

> Likewise, (p = NULL; and p == NULL) in C are both valid expressions 
> neither result in compiler warnings or errors (in strict compilers they 
> do)

They shouldn't. The first assigns the NULL value to a pointer. The 
second compares a pointer with NULL. That's all perfectly legal.

> But there is a difference between how they operate on the expression 
> (p = NULL + p) and (p = 0 + p) which is similar to the case we are 
> talking abotu here.

Not really. Adding an integer to a pointer to the start of an array, 
gives you a pointer to an element in that array. So 0+p is legal. But if 
NULL is ((void)0), which is more common in C nowadays and is closer to 
Nil in that it is explicitly a pointer, then NULL+p is not legal.

And you had been talking about Nil+1, not Nil+p.

> So here is our questiuon: should FP allow the expression (p := nil + p)? 

Not for me to say, but I would expect it should not.

Frank