Re: GCC 4.0 Ada.Containers Cursor danger.

["Randy Brukardt" <randy@rrsoftware.com>]

"Matthew Heaney" <matthewjheaney@earthlink.net> wrote in message
news:uslyrv50w.fsf@earthlink.net...
...
> I had originally included checks that didn't require any extra storage
> overhead, controlled by the use of pragma Assert.  However, it turns out
> that even if you compile with assertion checks on, whether assertions
> are enabled is decided at the time of compilation of the generic.  And
> in the GNAT runtime, all checks (including constraint checks -- gulp!
> I'm still fixing that...) are turned off.  I wanted additional checks to
> be controlled by the user (at the point of instantiation), but I still
> haven't figured out how to do that.

Yuck. I agree that being able to control the checking somehow would be a
good thing. That probably will require some cooperation with the compiler
vendor, so it is up to the users to put the pressure on the vendors.

Using Assert to do that seems like a good idea. (But it wouldn't have any
effect on our code-shared implementation of generics, for the obvious
reason.)

> To make things absolutely bullet-proof, I think you'd need at least a
> per-element reference count.  (That, or have the container maintain a
> list of extant cursors, which you would then have to search.)  If you
> attempt to delete a node for which the ref count is greater than 0, then
> you could raise an exception.  (This might actually produce a false
> positive, since the real error is attempting to dereference the cursor,
> not merely delete the node to which it is bound.  But to solve that,
> you'd have to move the node onto a free list, and during the dereference
> check to see whether the node is on the free list or not.)

Yes, and I agree that is too much overhead. I'm planning to use a serial
number scheme. It won't detect every possible error (if the memory for the
element or container as a whole is reused, there would be a very small
chance that it would fail to detect an error), but it would catch the vast
majority of them.

> So yes, there are some extra checks that can be performed, but I still
> prefer to let the user control whether they're enabled.
>
> You are also correct about immaturity of implementations.  I'm still
> developing a set of unit tests for the containers.  (In fact, I found a
> bug this morning in the Merge operation of the list container.)  So
> there's still lots of work to do, especially with the post-York API
> coming down the pipe...

That's one of the things (other than pure lack of time) that's kept me from
starting an implementation. Some ACATS-style tests would be very welcome.

                           Randy.