Re: c2ada bug report filed

[Simon Wright <simon@pushface.org>]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Simon Wright" <simon@pushface.org> wrote in message 
> news:m24o6jovd3.fsf@pushface.org...
> ...
>> I shall have a think about this, the 'access' approach is certainly
>> neat. There's the question of whether null is allowed; if it is, and
>> customers are using Ada95, 'access' is ruled out.
>
> All anonymous access types in Ada 95 were null excluding; passing "null" to 
> them was not allowed. The ARG recommended that all Ada 95 compilers support 
> "not null" syntactically (it would have no effect at runtime) in order to 
> minimize the incompatibility problems of switching back and forth between 
> Ada 95 and Ada 2005. Don't know if that recommendation was adopted widely (I 
> believe that Janus/Ada does allow it in Ada 95 mode).
>
> Either "in" or "access" in Ada 95 would not allow null, so if that is 
> needed, a named access type has to be used. Ada 2005 would require "not 
> null" if null is to be excluded (as noted, Ada 95 compilers are supposed to 
> support that, but who knows how many do).
>
> I personally don't like seeing access in any interface that can avoid it. 
> But if you need to be able to pass null, you don't have a choice. If not, I 
> think "in" is preferred.

It took me a moment to see your point! which is, I think, that (from ARM
B.3) pragma Convention (C) will pass structs and arrays as pointers
anyway. Hmm.

A binding generator will have trouble distinguishing the parameter mode,
of course.