[fpc-pascal] IE 200307043

Prince Riley wmarketing3 at gmail.com
Wed May 27 19:26:20 CEST 2009


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.'

FP uses the special address constant, 'nil' in much the same way. If you
assign a pointer a valid address and perform valid operations on it, say you
repeatedly decrement or shift it (arithmetic) you could produce an invalid
address. But it would not be 'nil'.

Nil is, by definition, an address; albiet, a special one  like the
mathmatical set theory concept of 'empty  or null set'.  Nil is defined as a
'meta value' and as such whatever the lowest address value in the range of
addresses actually is, nil is defined not a member of that set.

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.

The 'value' such an expression has must be defined in some way just as nil
is a defined lanuage constant; a way that consistently signals
('represents') the expression or operation produces an invalid result. So in
the example given there are two possible decisions

p := p + nil;   is INVALID (expression is valid, operands valid but result
is invalid) -- execution error, execution addressing exception

or

p := p + nil; is UNDEFINED (expression is invalid, no operation, no result)
-- compiler error


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.

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) {...}'

Likewise, (p = NULL; and p == NULL) in C are both valid expressions neither
result in compiler warnings or errors (in strict compilers they do) 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.

So here is our questiuon: should FP allow the expression (p := nil + p)? If
so, what should the result be? I opt that FP should treat it as an invalid
expression (compile error) and not as a valid expression with an UNDEFINED
value. I realize that this differs from what others might think or suggest.


On Wed, May 27, 2009 at 7:49 AM, Frank Peelo <f26p at eircom.net> wrote:

> Prince Riley wrote:
>
>>
>> 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
>>
>
> "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."
>
> I'm only quibbling with the equation of "doesn't reference anything" with
> "lowest possible value in the range". On many architectures, a pointer value
> of 0 might be a reasonable choice for "doesn't reference anything" because
> the CPU has interrupt vectors there, or uses address 0 for something else.
> But my point is that this is not guaranteed. Nil might not even point to
> valid data memory.
>
>  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.
>>
>
> But I'm more puzzled by what it would /mean/. In spite of your bracketed
> comment here, you seem to be thinking that nil is an address: i.e.
> adding/subtracting/multiplying a literal would mean something. I'm just
> pointing out that, if you think it's an address, it's undefined. Because
> it's not any address. So adding something to it doesn't mean anything.
>
> ...
>
>> 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).
>>
>
> Yup, GIGO.
>
>
> 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/20090527/007fd35b/attachment.html>


More information about the fpc-pascal mailing list