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-Thread: 103376,1ea59bb198e88f9f,start X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.maxwell.syr.edu!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!in.100proofnews.com!in.100proofnews.com!snoopy.risq.qc.ca!news.uunet.ca!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: GNAT Ada.Streams Bug? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Thu, 25 Nov 2004 12:41:29 -0500 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1101404427 198.96.223.163 (Thu, 25 Nov 2004 12:40:27 EST) NNTP-Posting-Date: Thu, 25 Nov 2004 12:40:27 EST Organization: Bell Sympatico Xref: g2news1.google.com comp.lang.ada:6472 Date: 2004-11-25T12:41:29-05:00 List-Id: This is on gnat-3.14p on debian (debian's package library doesn't seem to provide 3.15p), so this may be fixed by now: I am running into a Ada.Streams problem with 24 bit values (3 bytes). For example, if you use Ada.Streams to read in a partition table, defined as follows, with 3.14p, you'll read more bytes than needed (thus messing things up): type chs_t is mod 2**24; -- Cylinder/Head/Sector for chs_t'size use 24; -- All other types below are 8, 16 or 32 bits wide type Partition_Type is record Flags : part_flags_t; -- Partition flags CHS_Start : chs_t; -- Cyl/Head/Sector Start Kind : part_kind_t; -- Partition Type CHS_End : chs_t; -- Cyl/Head/Sector End LBA_Start : part_offset_t; -- LBA Offset LBA_Size : part_size_t; -- LBA Size end record; for Partition_Type use record Flags at 0 range 0..7; CHS_Start at 1 range 0..23; Kind at 4 range 0..7; CHS_End at 5 range 0..23; LBA_Start at 8 range 0..31; LBA_Size at 12 range 0..31; end record; type Partition_Array is array(Natural range 1..4) of Partition_Type; When Partition_Type'Read(Stream,Part_Table) didn't work correctly, I put debugging statements into the 'Read routine, and saw to my horror that the CHS_Start and CHS_End values are read in as 4 byte values, instead of 3! So when chs_t'Read is called, it wants STREAM_ELEMENT_ARRAY(1..4) filled, instead of the expected 1..3 slice. Questions for the Group: 1. Can I assume this is a bug? (I am not a language lawyer) 2. Does anyone know if this has been fixed in gnat-3.15p or later? It seems that if I stick to powers of 2 for data element sizes, things work as expected. The work around is to divide up the chs_t type. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg