[fpc-pascal] IE 200307043

[Prince Riley]

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 <f26p at 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 at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20090526/306d358b/attachment.html>