String Pointer Bug

String Pointer Bug

[skidmarks]

(Program below): The same code fragment was run on two different
compilers, GNAT and another commercial vendor, 'compiler. The results
are inconsistent and I don't believe that both sets of errors can be
correct. Before I scream and holler, I wonder if there are wiser heads
who can provide insight into which (if any) compiler version is
incorrect.

The summary is that a pointer to a definite type and a pointer to an
indefinite typed value have different constraints, detected and
reported. I would assume that compliant compilers would complain
similarly.

Thanks

art
------------------------------ C O D E ------------------------------

procedure Bug is

  type String_Ptr     is access all String;

  subtype Str_Ptr     is String_Ptr( 1 .. 12 );
  
  type String_Array   is array( 1 .. 68 ) of aliased String( 1 .. 12
);
  
  Input         : String_Array := ( others => (others => ' ') );
  StrArray      : array( 1 .. 68 ) of aliased String( 1 .. 12 );
  Strng         : aliased String            := "one two three";
  --      GNAT warning not issued by Compiler
  --      >>> warning: aliased object has explicit bounds
  --      >>> warning: declare without bounds (and with explicit
initialization)
  --      >>> warning: for use with unconstrained access
  Str           : String_Ptr;
  Str_Def       : Str_Ptr;

  -- Compiler Diagnostic Message
  -- LRM:3.10.2(27) The nominal subtype of the prefix to 'ACCESS or
  --                'UNCHECKED_ACCESS must either statically match
  --                the expected type or the designated subtype must
be
  --                discriminated and unconstrained

  -- GNAT (gcc-3.3.1 & gcc-3.3.3)
  -- object subtype must statically match designated subtype

  --                                   Error Messages (See above)
begin -- Bug                          GNAT   COMPILER
   Str      := Input(1)'Access;     --  X      X
   Str      := StrArray(1)'Access;  --  X      X
   Str      := Strng'Access;
   
   Str_Def  := Input(1)'Access;     --         X
   Str_Def  := StrArray(1)'Access;  --         X
   Str_Def  := Strng'Access;        --  X
end Bug;

Re: String Pointer Bug

[Per Sandberg]

Running GNAT Pro 5.03w (20041005-34)/ gcc-3.4.3  i get exactly the same 
messages as "compiler"

/Per


skidmarks wrote:

>(Program below): The same code fragment was run on two different
>compilers, GNAT and another commercial vendor, 'compiler. The results
>are inconsistent and I don't believe that both sets of errors can be
>correct. Before I scream and holler, I wonder if there are wiser heads
>who can provide insight into which (if any) compiler version is
>incorrect.
>
>The summary is that a pointer to a definite type and a pointer to an
>indefinite typed value have different constraints, detected and
>reported. I would assume that compliant compilers would complain
>similarly.
>
>Thanks
>
>art
>------------------------------ C O D E ------------------------------
>
>procedure Bug is
>
>  type String_Ptr     is access all String;
>
>  subtype Str_Ptr     is String_Ptr( 1 .. 12 );
>  
>  type String_Array   is array( 1 .. 68 ) of aliased String( 1 .. 12
>);
>  
>  Input         : String_Array := ( others => (others => ' ') );
>  StrArray      : array( 1 .. 68 ) of aliased String( 1 .. 12 );
>  Strng         : aliased String            := "one two three";
>  --      GNAT warning not issued by Compiler
>  --      >>> warning: aliased object has explicit bounds
>  --      >>> warning: declare without bounds (and with explicit
>initialization)
>  --      >>> warning: for use with unconstrained access
>  Str           : String_Ptr;
>  Str_Def       : Str_Ptr;
>
>  -- Compiler Diagnostic Message
>  -- LRM:3.10.2(27) The nominal subtype of the prefix to 'ACCESS or
>  --                'UNCHECKED_ACCESS must either statically match
>  --                the expected type or the designated subtype must
>be
>  --                discriminated and unconstrained
>
>  -- GNAT (gcc-3.3.1 & gcc-3.3.3)
>  -- object subtype must statically match designated subtype
>
>  --                                   Error Messages (See above)
>begin -- Bug                          GNAT   COMPILER
>   Str      := Input(1)'Access;     --  X      X
>   Str      := StrArray(1)'Access;  --  X      X
>   Str      := Strng'Access;
>   
>   Str_Def  := Input(1)'Access;     --         X
>   Str_Def  := StrArray(1)'Access;  --         X
>   Str_Def  := Strng'Access;        --  X
>end Bug;
>_______________________________________________
>comp.lang.ada mailing list
>comp.lang.ada@ada-france.org
>http://www.ada-france.org/mailman/listinfo/comp.lang.ada
>
>  
>

Re: String Pointer Bug

[Christoph Karl Walter Grein]

A long time ago, I made an exegesis of this problem. You may find it below
(sorry if the indentation should be lost, it's my mailer that swallows it, I do not know
to avoid this):

procedure Try is

  type D is array (Integer range <>) of Boolean;
  type A is access all D;

  X: aliased D (1..3);
  AX: A           := X'Access;  -- not OK
  BX: A (X'Range) := X'Access;  -- not OK

  Y: aliased D := X;
  AY: A           := Y'Access;  --   OK
  BY: A (Y'Range) := Y'Access;  -- OK

begin

  null;

end Try;
----------------------------------------------------
-- My exegesis:
--
-- RM 3.3.1(8,9)
--
--          Nominal     Actual
--                subtype
--    X     D (1..3)    D (1..3)
--    Y     D           D (1..3)
--
-- So the actual subtypes are constrained.
-- X is a constrained object because its nominal subtype is constrained
-- and Y is an object constrained by its initial value.
--
-- RM 3.10(10)
--
--    Designated subtype of A and A (X'Range) and A (Y'Range) is D.
--
-- RM 3.10.2(27/1)
--
--    A's designated subtype shall statically match the nominal subtype
--    of the view.
--
-- RM 4.9.1 (2)
--
--    Statically matching subtypes have statically matching constraints.
--
-- AX: Expected type of X'Access is A.
--     A's designated subtype D does not statically match X's nominal
--     subtype D(1..3).
--
-- BX: Expected type of X'Access is A(X'Range).
--     A(X'Range)'s designated subtype D does not statically match X's
--     nominal subtype D(1..3).
--
-- AY: Expected type of Y'Access is A.
--     A's designated subtype D does statically match Y's nominal subtype D.
--
-- BY: Expected type of Y'Access is A(Y'Range).
--     A(Y'Range)'s designated subtype D does statically match Y's nominal
--     subtype D.
__________________________________________________________
Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201

Re: String Pointer Bug

[skidmarks]

"Christoph Karl Walter Grein" <AdaMagica@web.de> wrote in message news:<mailman.83.1099920902.10401.comp.lang.ada@ada-france.org>...
> A long time ago, I made an exegesis of this problem. You may find it below
> (sorry if the indentation should be lost, it's my mailer that swallows it, I do not know
> to avoid this):

Thank you. This is an excellent description. the only (fault) that I
can see is that it requires a copy operation (Y: aliased D := X).

I wonder, do you think that:

   Y: aliased D; for Y'Address use X'Address;

is a viable alternative (please note, I did not say GOOD alternative).

In this simple case, a copy serves no harm, other than some time. But
if the data is large the cost will certainly grow, perhaps to being
unacceptable.

Another (but unattractive) alternative might be:

    type S1 is String(1..1);
    type S2 is String(1..2);
             ooo
    type Sn is String(1..n);

    type S_Ptr  is access all String;
    type S1_Ptr is access all S1;
             ooo
    type Sn_Ptr is access all Sn;


and so on. But how really ugly.

thanks

art

Re: String Pointer Bug

[Martin Krischik]

skidmarks wrote:

> "Christoph Karl Walter Grein" <AdaMagica@web.de> wrote in message
> news:<mailman.83.1099920902.10401.comp.lang.ada@ada-france.org>...
>> A long time ago, I made an exegesis of this problem. You may find it
>> below (sorry if the indentation should be lost, it's my mailer that
>> swallows it, I do not know to avoid this):
> 
> Thank you. This is an excellent description. the only (fault) that I
> can see is that it requires a copy operation (Y: aliased D := X).
> 
> I wonder, do you think that:
> 
>    Y: aliased D; for Y'Address use X'Address;
> 
> is a viable alternative (please note, I did not say GOOD alternative).

for Y'Address use X'Address; is an form of Unchecked_Unchecked_Conversion or
on C++ talk a reinterpret_cast - the kind of convertion where no,
absolutely no, check is done. Is is a solution where either performace is
on the essence or nothing else goes.

But yes it is a solution. Viable? Well, your decision. 

With Regards

Martin

PS: I did use Y'Address use X'Address; once for converting C <-> Ada strings
where I wanted better performace then Interfaces.C.

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com