Frank,
I think the crux of the matter here is how to make the distinction between a
pointer with 'no value' and one that is initialized or set to the 'lowest
possible value in the range'. The quote I mentioned comes directly from
Borland's Object Pascal Langage Manual
You can check on this, but when I looked it up the 'nil' constant in a
Object Pascal Language reference and what the reserved word 'nil' , a
special constant, means in terms of pointer value (it's not an address) I
was not able to find and what adding/subtracting/multiplying it by a
literal numeric value (or another valid pointer value) to 'nil' would
create.
If you're interested in the details (they are very instructive) compile a
sample program with the two programs on an Intel based machine and then
check the generated code with the GNU Debugger. Set a break point on the
following statement
p := nil;
and then single step to the next instruction. You'll see immediately that
two things happen: 1) the value assigned to 'p' by that statement is not a
valid segment/offset address (i32/i64 architecture). If you then set another
breakpoint on the next instruction,
p := p + 1;
you'll notice that the first thing that happens is 'p' get set to a valid
segment address and then the offset, and not the base segment, is
incremented by a value of '1' (again on a Intel CPU machine). Things get
even more interesting when 'p' is first typed, to an Integer for example,
and then assigned the 'nil' value. ....
var
R: Integer ;
P: Pointer;
IntArray1, IntArray2: array of Integer;
IP: ^Integer;
IntArrayPtr: Pointer;
begin
P := nil;
P := @R;
P := P + 1;
P := nil;
IntArray[0] := 1;
IntArray[1] := 1;
IP := @IntArray[0]
IP := IP + 1;
IntArrayPtr := @IntArray[1];
if IntArrayPtr^ <> IP^ then Writeln ("Integer Array values not the same");
end.
Setting breakpoints on the statements where values are assigned to 'P' and
'IP' and watching how their values are set, incremented, and dereferenced
will demonstrate how challenging even a simple pointer handling model can
be.
On Mon, May 25, 2009 at 10:57 PM, Frank Peelo <f...@eircom.net> wrote:
> Prince Riley wrote:
>
>> Hello,
>>
>>
>
>>
>> "The reserved word nil is a special constant that can be assigned to any
>> pointer. When nil is assigned to a pointer, the pointer doesn't reference
>> anything."
>>
>> Since a pointer is a memory address value, then the interpretation of the
>> statement "nil +1" would mean for p to point at the very next valid address
>> above the lowest memory address 'p' can hold.
>>
>
> That is an "interesting" interpretation of "doesn't reference anything".
> There is no guarantee that nil is address 0, although it may be so in any
> available compiler -- at least, any compiler targetting an architecture that
> does not have usable memory at address 0. Nil doesn't point at anything.
> It's an undefined address.
>
> So it would appear that 'p := nil + 1' should not compile or work.
>>
>
> That would be reasonable - although if nil /was/ 0, then nil+1 would be
> defined for any given pointer type, and a compiler /could/ make a stab at
> compiling it -- but probably /should not/. Because what would "1 more than
> undefined" mean?
>
> FP
>
>
>
>
> _______________________________________________
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
