From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII
X-Google-Thread: 103376,6216cea7ed8d90a9
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-03-04 18:06:07 PST
Path: 
 supernews.google.com!sn-xit-03!supernews.com!64.71.136.253.MISMATCH!news!news.he.net!nntp.primenet.com!nntp.gblx.net!dispose.news.demon.net!demon!grolier!btnet-peer0!btnet-feed5!btnet!carbon.eu.sun.com!new-usenet.uk.sun.com!not-for-mail
From: =?iso-8859-1?Q?Herv=E9?= Bitteur <Herve.Bitteur@France.Sun.COM>
Newsgroups: comp.lang.ada
Subject: Got bitten by GNAT.Table
Date: Mon, 05 Mar 2001 02:56:26 +0100
Organization: Sun Microsystems
Message-ID: <3AA2F24A.3843E70@France.Sun.COM>
References: <3AA0B68C.AD5F1242@blops.mydiax.ch>
 <LT8o6.2035$6i1.286659@news1.frmt1.sfba.home.com>
 <3AA2C4C4.CF3E6457@blops.mydiax.ch>
NNTP-Posting-Host: hobo134.eng.sun.com
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: new-usenet.uk.sun.com 983757347 2805 129.146.31.134 (5 Mar 2001
 01:55:47 GMT)
X-Complaints-To: usenet@new-usenet.uk.sun.com
NNTP-Posting-Date: 5 Mar 2001 01:55:47 GMT
X-Mailer: Mozilla 4.72 [en] (Win98; I)
X-Accept-Language: fr-FR,en
Xref: supernews.google.com comp.lang.ada:5419
Date: 2001-03-05T01:55:47+00:00
List-Id: <comp.lang.ada>

GNAT.Table is useful to provide dynamically growing arrays.
However I recently discovered the reason why I occasionally 
had other data overwritten, if not access violation errors.
Here is a simple test program that you can run from the command line,
with just one argument: the upper bound of the loop.

-------------------------------------------------------------------------
with GNAT.Table;
with Ada.Command_Line;
procedure Test_Table
is
   Init : constant Natural := Natural'Value (Ada.Command_Line.Argument
(1));
   package Pkg is new GNAT.Table
     (Table_Component_Type => Character,
      Table_Index_Type     => Natural,
      Table_Low_Bound      => 1,
      Table_Initial        => Init,
      Table_Increment      => 100);
begin
   for I in 1 .. Init + 1 loop          -- To force one reallocation
      Pkg.Table (Pkg.Allocate) := 'a';  -- <<<<<
   end loop;
end Test_Table;
-------------------------------------------------------------------------

On my Windows 98 environment, using GNAT 3.13p, 
I'm getting the following results :

$> test_table 523200
(or less than 523200) is OK, but

$> test_table 523201
(or higher) leads to:
raised PROGRAM_ERROR : EXCEPTION_ACCESS_VIOLATION

Using Integers (4 bytes) instead of Characters (1 byte) also crashes,
the limit is slightly higher (I would have expected a lower limit).

Anyway, if I modify the little program (line marked with -- <<<<<)
so that instead of
      Pkg.Table (Pkg.Allocate) := 'a';
I use
      declare
         Last : Natural := Pkg.Allocate;
      begin
         Pkg.Table (Last) := 'a';
      end;
The program then runs OK. For example test_table 100_000_000 is fine
(1_000_000_000 however raises storage_error, but I can understand this)

How could we explain the result?
If the call to GNAT.Table.Allocate results in an actual reallocation
of the buffer, then at this precise moment, we modify the very value
of Table which is in fact an array reference.
- Allocate increases the current Last value and returns the previous
last value +1
- Table (xxx) is the combination of dereferencement + indexation.
The problem is that when we've reached the end of the allocated array,
the Allocate function reallocates the array, thus changing the array
reference ON-THE-FLY.

I should dig into the generated code but I suspect that the construction 
"Table (Allocate)" is not kept coherent when the array is reallocated, 
so the need to explicitly separate the two operations.

To prevent this, I would suggest to replace the Allocate function, by
a simple procedure. Any one can still retrieve the current last value,
by calling the Table.Last function.

Bye,
-- Herv�

-- 
      /\             Herv� BITTEUR                            
     \\ \            EMEA IT Architect
    \ \\ /           SUN MICROSYSTEMS FRANCE                  
   / \/ / /          13, avenue Morane Saulnier
  / /   \//\         78142 V�lizy cedex France
  \//\   / /         
   / / /\ /          Email  : Herve.Bitteur@France.Sun.COM
    / \\ \           Office : +33 (0)1.30.67.51.12
     \ \\            
      \/             Fax.   : +33 (0)1.30.67.53.06