Hello Frank,<br><br>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.'  <br>

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

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

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

<br>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<br>

<br><div style="margin-left: 40px;">p := p + nil;   is INVALID (expression is valid, operands valid but result is invalid) -- execution error, execution addressing exception <br><br>or<br><br>p := p + nil; is UNDEFINED (expression is invalid, no operation, no result) -- compiler error<br>

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

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

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

<br><div class="gmail_quote">On Wed, May 27, 2009 at 7:49 AM, Frank Peelo <span dir="ltr"><<a href="mailto:f26p@eircom.net">f26p@eircom.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="im">Prince Riley wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Frank,<br>
<br>
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<br>


</blockquote>
<br></div><div class="im">
"The reserved word nil is a special constant that can be<br>
assigned to any pointer. When nil is assigned to a pointer, the<br>
pointer doesn't reference anything."<br>
<br></div>
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.<div class="im">

<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>


</blockquote>
<br></div>
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.<br>


<br>
...<div class="im"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If you then set another breakpoint on the next instruction, <br>
p := p + 1;<br>
<br>
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). <br>


</blockquote>
<br></div>
Yup, GIGO.<div><div></div><div class="h5"><br>
<br>
FP<br>
<br>
<br>
_______________________________________________<br>
fpc-pascal maillist  -  <a href="mailto:fpc-pascal@lists.freepascal.org" target="_blank">fpc-pascal@lists.freepascal.org</a><br>
<a href="http://lists.freepascal.org/mailman/listinfo/fpc-pascal" target="_blank">http://lists.freepascal.org/mailman/listinfo/fpc-pascal</a><br>
</div></div></blockquote></div><br>