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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
