Re: Ada array vs C pointer (call by reference)

[Keith Thompson <kst-u@mib.org>]

Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de> writes:
> Maciej Sobczak wrote:
> > On 27 Cze, 16:43, Georg Bauhaus <rm.tsoh.plus-
> > bug.bauh...@maps.futureapps.de> wrote:
> > 
> >>> Is there any implementation where Interfaces.C.int has different
> >>> properties than Integer?
> ...
> >> procedure Cint is
> >>    use Interfaces;
> >>    use type C.int;
> >>
> >>    X: C.int;
> >> begin
> >>    X := C.int'last;
> >>    X := X + 1;
> >> end;
> > 
> > CONSTRAINT_ERROR - overflow check failed.
> > I get the same with Integer.
> > 
> > What is the difference then?
> 
> I should have made the example adress the difference
> between the Ada types Integer and C.int as a representative
> of C's int behavior.
> In code that uses C integers I'll see C.int used, and
> hence meaningfully different types. This points me to
> different behavior on the C side even when inside Ada
> it makes no difference:
> 
> int inc(int x) { return x + 1; }
> 
> with Interfaces.C, Ada.Text_IO;
> 
> procedure Cint is
>    use Interfaces;
>    use type C.int;
> 
>    function C_inc(X: C.int) return C.int;
>    pragma import(C, C_inc, "inc");
> 
>    X: C.int;
> begin
>    X := C.int'last;
>    X := C_inc(X);
>    Ada.Text_IO.Put_Line(C.int'image(X));
> end;
> 
> prompt>cint
> -2147483648

Strictly speaking, signed integer overflow in C invokes undefined
behavior (what Ada calls "erroneous execution").

Two's-complement wraparound is certainly the most common behavior for
most C implementations, but a C optimizer can alter the generated code
based on the assumption that the overflow won't happen.  (That's not
likely in this particular case.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"