Re: Does a null pointer always raise Constraint_Error?

Re: Does a null pointer always raise Constraint_Error?

[Wayne Magor]

Mike Silva wrote:

> How does one choose the null value?  I understand that the null value
> need not be zero, but I always thought it was fixed in a given
> compiler, or perhaps CPU architecture.

I remember with one Ada compiler I wanted to make null to be a pointer to a
zero-length segment so
the null check would be unnecessary (the hardware would do it for you).  I
seem to remember there was
a problem with this.  Either the hardware guys never considered that you
might want a zero-length segment
or we wanted to be compatible with the null from C (I think it was the h/w
problem).

In any case, for those h/w types that might read this...  please allow for
zero-length segments!  I believe this
is the "best" implementation for null.

Wayne.

Re: Does a null pointer always raise Constraint_Error?

[Keith Thompson]

Wayne Magor <none@nowhere.com> writes:
[...]
> I remember with one Ada compiler I wanted to make null to be a
> pointer to a zero-length segment so the null check would be
> unnecessary (the hardware would do it for you).

Would a zero-length segment be a good way to represent a zero-size
object?  If so, a pointer to a zero-length segment might be valid.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: Does a null pointer always raise Constraint_Error?

[Robert Dewar]

In article <yec1yvdtmf1.fsf@king.cts.com>,
  Keith Thompson <kst@cts.com> wrote:
> Wayne Magor <none@nowhere.com> writes:
> [...]
> > I remember with one Ada compiler I wanted to make null to be
a
> > pointer to a zero-length segment so the null check would be
> > unnecessary (the hardware would do it for you).

No, that's not quite right, you can still miss things, consider

   subtype n is string (1 .. 0);
   type np is access n;
   a, b : np;

   if a.all = b.all then ...

it is a common compiler bug to translate this as

   for j in n'range loop
     if a.all (j) = b.all (j) ....

and the null loop causes no checks to be made :-)


Sent via Deja.com
http://www.deja.com/

Re: Does a null pointer always raise Constraint_Error?

[Lutz Donnerhacke]

* Robert Dewar wrote:
[access to empty arrays represent as Null (System.Address)]
>   subtype n is string (1 .. 0);
>   type np is access n;
>   a, b : np;
>
>   if a.all = b.all then ...
>
>it is a common compiler bug to translate this as
>
>   for j in n'range loop
>     if a.all (j) = b.all (j) ....
>
>and the null loop causes no checks to be made :-)

I do not see the bug.

-- 
	      http://www.tm.oneiros.de/calendar/2001/index.html

Re: Does a null pointer always raise Constraint_Error?

[Ken Garlington]

"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrn93eect.i1.lutz@taranis.iks-jena.de...
: * Robert Dewar wrote:
: [access to empty arrays represent as Null (System.Address)]
: >   subtype n is string (1 .. 0);
: >   type np is access n;
: >   a, b : np;
: >
: >   if a.all = b.all then ...
: >
: >it is a common compiler bug to translate this as
: >
: >   for j in n'range loop
: >     if a.all (j) = b.all (j) ....
: >
: >and the null loop causes no checks to be made :-)
:
: I do not see the bug.

Probably explains why it's so common...

(I'm guessing it might have something to do with the case where a or b are
null. Presumably, no exception would be raised if the compiler generated
this kind of code, due to n'range causing the body of the loop to be skipped
altogether?)

Re: Does a null pointer always raise Constraint_Error?

[Lutz Donnerhacke]

* Ken Garlington wrote:
>"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
>: * Robert Dewar wrote:
>: [access to empty arrays represent as Null (System.Address)]
>: >   subtype n is string (1 .. 0);
>: >   type np is access n;
>: >   a, b : np;
>: >
>: >   if a.all = b.all then ...
>: >
>: >it is a common compiler bug to translate this as
>: >
>: >   for j in n'range loop
>: >     if a.all (j) = b.all (j) ....
>: >
>: >and the null loop causes no checks to be made :-)
>:
>: I do not see the bug.
>
>Probably explains why it's so common...
>
>(I'm guessing it might have something to do with the case where a or b are
>null. Presumably, no exception would be raised if the compiler generated
>this kind of code, due to n'range causing the body of the loop to be
>skipped altogether?)

Possible, but irrelevant IMHO. Two empty arrays of the same component type
are equal per definition.


-- 
	      http://www.tm.oneiros.de/calendar/2001/index.html

Re: Does a null pointer always raise Constraint_Error?

[Florian Weimer]

lutz@iks-jena.de (Lutz Donnerhacke) writes:

> * Ken Garlington wrote:
> >"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
> >: * Robert Dewar wrote:
> >: [access to empty arrays represent as Null (System.Address)]
> >: >   subtype n is string (1 .. 0);
> >: >   type np is access n;
> >: >   a, b : np;
> >: >
> >: >   if a.all = b.all then ...
> >: >
> >: >it is a common compiler bug to translate this as
> >: >
> >: >   for j in n'range loop
> >: >     if a.all (j) = b.all (j) ....
> >: >
> >: >and the null loop causes no checks to be made :-)

> Possible, but irrelevant IMHO. Two empty arrays of the same component type
> are equal per definition.

There a two language-defined checks involved prior to the array
comparison.  However, 11.6(5) seems to permit the omission of these
checks, but I'm not sure about that.

Re: Does a null pointer always raise Constraint_Error?

[Lutz Donnerhacke]

* Florian Weimer wrote:
>There a two language-defined checks involved prior to the array
>comparison.  However, 11.6(5) seems to permit the omission of these
>checks, but I'm not sure about that.

Relational Operators and Membership Tests

16.
    2. For two one-dimensional arrays of the same type, matching components
       are those (if any) whose index values match in the following sense:
       the lower bounds of the index ranges are defined to match, and the
       successors of matching indices are defined to match;

The only problem can be to do not dereference the access variables first.

Yep: I see the bug. Thanx everybody.

-- 
	      http://www.tm.oneiros.de/calendar/2001/index.html

Re: Does a null pointer always raise Constraint_Error?

[Robert Dewar]

In article
<tgn1e0mkqh.fsf@mercury.rus.uni-stuttgart.de>,
  Florian Weimer
<Florian.Weimer@RUS.Uni-Stuttgart.DE> wrote:
> There a two language-defined checks involved prior
> to the array comparison.  However, 11.6(5) seems to
> permit the omission of these checks, but I'm not
> sure about that.

Nobody is sure about 11.6 :-)

I don't think it applies however. Why not? Because
the program does indeed depend on the result of this
comparison. If you did

  Junk := a.all = b.all;

and never referenced junk, then you could use
11.6(5) to argue that the check should be omitted.


Sent via Deja.com
http://www.deja.com/

Re: Does a null pointer always raise Constraint_Error?

[Florian Weimer]

Robert Dewar <robert_dewar@my-deja.com> writes:

> > There a two language-defined checks involved prior
> > to the array comparison.  However, 11.6(5) seems to
> > permit the omission of these checks, but I'm not
> > sure about that.
> 
> Nobody is sure about 11.6 :-)

:-)

> I don't think it applies however. Why not? Because
> the program does indeed depend on the result of this
> comparison. If you did
> 
>   Junk := a.all = b.all;
> 
> and never referenced junk, then you could use
> 11.6(5) to argue that the check should be omitted.

That's one of the simple cases everybody seems to be happy with.

I would argue that a.all and b.all are undefined, but because of their
type, their values can be compared with a well-defined result anyway.

Re: Does a null pointer always raise Constraint_Error?

[Robert Dewar]

In article <87zoi0w0ey.fsf@deneb.enyo.de>,
  Florian Weimer <fw@deneb.enyo.de> wrote:
> I would argue that a.all and b.all are undefined,
> but because of their type, their values can be
> compared with a well-defined result anyway.

I understand that argument, but I cannot see that
it is backed by the language in the RM. Furthermore,
there is an ACATS test that disputes this conclusion,
and no one has ever contested this test.


Sent via Deja.com
http://www.deja.com/

Re: Does a null pointer always raise Constraint_Error?

[Ken Garlington]

"Robert Dewar" <robert_dewar@my-deja.com> wrote in message
news:91agoe$kvf$1@nnrp1.deja.com...
: In article <87zoi0w0ey.fsf@deneb.enyo.de>,
:   Florian Weimer <fw@deneb.enyo.de> wrote:
: > I would argue that a.all and b.all are undefined,
: > but because of their type, their values can be
: > compared with a well-defined result anyway.
:
: I understand that argument, but I cannot see that
: it is backed by the language in the RM. Furthermore,
: there is an ACATS test that disputes this conclusion,
: and no one has ever contested this test.

The ACATS test seems to be consistent with the rest of the language. For
example, I'd assume that the following wouldn't work, either:

if (A/0) = (B/0) then...

Re: Does a null pointer always raise Constraint_Error?

[Robert Dewar]

In article <hP4_5.7975$bw.730724@news.flash.net>,
  "Ken Garlington" <Ken.Garlington@computer.org>
wrote:

> if (A/0) = (B/0) then...


That's a little more obviously wrong, because there
is no basis for producing values that are equal, but
in the null array case, it is surely the case that
ALL objects of the type are equal, so equality for
that type is always true -- a little more subtle than
the above example, but I think still bogus.



Sent via Deja.com
http://www.deja.com/

Re: Does a null pointer always raise Constraint_Error?

[Robert Dewar]

In article <slrn93f1ic.vo.lutz@taranis.iks-jena.de>,
  lutz@iks-jena.de (Lutz Donnerhacke) wrote:
> Possible, but irrelevant IMHO. Two empty arrays of
> the same component type
> are equal per definition.

THis is an easy HO to have, and that is why I noted
the example, but look more carefully at my example,
it is not comparing empty arrays, it is comparing
deferenced null pointers, and a constraint error
is required even though there is nothing to compare!

Actually, in this simple form, a compiler is not
likely to get this wrong, since there are simple
examples like this in the ACATS test suite.


Sent via Deja.com
http://www.deja.com/

Re: Does a null pointer always raise Constraint_Error?

[Keith Thompson]

Wayne Magor <none@nowhere.com> writes:
[...]

BTW, I presume "none@nowhere.com" is a fake address intended to block
spammers.  Keep in mind that there really is a nowhere.com, and their
servers could be hit by spam sent to your fake address.  If you want
to block spam, use an address that can't possibly be valid, such as
"none@nowhere.invalid".

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: Does a null pointer always raise Constraint_Error?

[Florian Weimer]

Keith Thompson <kst@cts.com> writes:

> BTW, I presume "none@nowhere.com" is a fake address intended to block
> spammers.  Keep in mind that there really is a nowhere.com, and their
> servers could be hit by spam sent to your fake address.  If you want
> to block spam, use an address that can't possibly be valid, such as
> "none@nowhere.invalid".

With the result that several people won't read the article. ;-)

Re: Does a null pointer always raise Constraint_Error?

[Robert Dewar]

In article <3A36511D.973D82BD@nowhere.com>,
  Wayne Magor <none@nowhere.com> wrote:
> In any case, for those h/w types that might read this...
please allow for
> zero-length segments!  I believe this
> is the "best" implementation for null.


I know of no architecture where zero length segments do not
work in the obvious manner. I suspect this is a bogus memory.
If you think not, please give architectural details.


Sent via Deja.com
http://www.deja.com/