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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Thread: 103376,7722b78486dfd336,start X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!proxad.net!usenet-fr.net!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: Lionel.DRAGHI@fr.thalesgroup.com Newsgroups: comp.lang.ada Subject: RE: Zero_Fill pragma, other proposition Date: Wed, 21 Jul 2004 11:20:32 +0200 Organization: Cuivre, Argent, Or Message-ID: NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: melchior.cuivre.fr.eu.org 1090401710 32048 212.85.156.195 (21 Jul 2004 09:21:50 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Wed, 21 Jul 2004 09:21:50 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: X-Mailer: Internet Mail Service (5.5.2653.19) X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Gateway to the comp.lang.ada Usenet newsgroup" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: g2news1.google.com comp.lang.ada:2308 Date: 2004-07-21T11:20:32+02:00 | -----Message d'origine----- | De: Jean-Pierre Rosen [mailto:rosen@adalog.fr] ... | OTOH, I suspect that very few types would need | that pragma (as you describe, a couple of types very strongly | connected to hardware), so writing more fields is not really a | problem. In our case, it's a common problem : we have lots of messages with spare fields, and setting them to 0 for out going messages is a requirement. (On the other hand, even without this requirement, it would ease regression testing. Simple regression test tools based on diff raise false alarm because spare fields may be whatever on each run). So, our current policy is to explicitly state each spare. I don't feel confortable with this because the low level representation emerge in the definition. I don't want users to access the spare fields. I don't event want users to see the spare fields. What could be a good deal is to allows spare fields to appear in the representation clause. Kind of : type Message is record Id : Message_Id; Data : Byte_Stream; end record; for Message use record Id at 0 range 0 .. 7; Spare at 0 range 8 .. 15 := 0; --> ADDED Data at 0 range 16 .. 65; end record; This way, representation stuff don't emerge in the "user's" view, but spares are explicit in the "coder's" view. -- Lionel Draghi