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,ab43ecf7e1a10743 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: Zero_Fill pragma Date: Tue, 20 Jul 2004 21:14:15 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: news.uni-berlin.de E0ZfTDbgkvwUbmyM29W16QzMGgxMSSO0L1Pi137URbpwq9v6A= User-Agent: Opera M2/7.51 (Win32, build 3798) Xref: g2news1.google.com comp.lang.ada:2289 Date: 2004-07-20T21:14:15+01:00 List-Id: On Tue, 20 Jul 2004 19:37:18 +0200, Jean-Pierre Rosen wrote: > "Nick Roberts" a �crit dans le message de > news:opsbf2fpb0p4pfvb@bram-2... >> Am I too late to make a proposal for a new pragma for >> the Ada 2005 Amendment? > Yes Well that makes the matter moot anyway, I suppose. >> It would have the syntax: >> >> pragma Zero_Fill(simple_name); >> [...] >> Either way, I think the pragma would be useful in real >> programs, > I would not think so. > 1) There is nothing special with the value 0 in Ada. You can > have (easily) types where value 0 does not belong to the > type, therefore 0 would not be better than any random value. Jean-Pierre, I suspect you did not understand the intended meaning of this pragma. Perhaps I described it badly (sorry). The pragma is not intended to affect any of the bits that are used to represent a value. In a composite type, you sometimes get 'gaps' in between components (or possibly at the edges), of 'unused' bits. The pragma is intended to cause these unused bits to be initialised to 0 whenever the composite object as a whole is initialised. It is not intended to affect the initialisation (or reading or updating) of any of the components. The purpose of the pragma is for use in interfacing, either with hardware or with data in any externally defined format. It is quite often the case, when doing this, that a composite value has gaps which (according to the hardware design or data definition) must be kept 0. Although this can be done explicitly using 'dummy' components, it is a pain doing so, and I think it can reduce the readability and maintainability of code. I think the suggested pragma would be better. Suppose we wished to declare a record to represent the EFLAGS register of the IA-32: type Flags_32 is record C: Boolean; -- carry P: Boolean; -- parity A: Boolean; -- auxiliary carry Z: Boolean; -- zero S: Boolean; -- sign T: Boolean; -- trap I: Boolean; -- interrupt D: Boolean; -- direction O: Boolean; -- overflow IOPL: Privilege_Level; -- I/O privilege level NT: Boolean; -- nested task RF: Boolean; -- resume VM: Boolean; -- virtual mode AC: Boolean; -- alignment check end record; for Flags_32 use record C at 0 range 0 .. 0; P at 0 range 2 .. 2; A at 0 range 4 .. 4; Z at 0 range 6 .. 6; S at 0 range 7 .. 7; T at 0 range 8 .. 8; I at 0 range 9 .. 9; D at 0 range 10 .. 10; O at 0 range 11 .. 11; IOPL at 0 range 12 .. 13; NT at 0 range 14 .. 14; RF at 0 range 16 .. 16; VM at 0 range 17 .. 17; AC at 0 range 18 .. 18; end record; for Flags_32'Size use 32; It is important that the 17 bits not defined by the above representation clause are initialised to 0 in objects of this type. It would be truly yukky to have to declare another 17 dummy booleans to achieve this effect. It would surely be much preferable to be able to just declare: pragma Zero_Fill(Flags_32); -- Nick Roberts