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-7-bit X-Google-Thread: 103376,47208e1e64e89fe0 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-10-10 08:38:39 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!uunet!sea.uu.net!ash.uu.net!world!news From: Robert A Duff Subject: Re: Null Record is not always Null User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Sender: news@world.std.com (Mr Usenet Himself) Message-ID: Date: Thu, 10 Oct 2002 15:38:05 GMT Content-Type: text/plain; charset=us-ascii References: <1b585154.0210100512.54af8543@posting.google.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Organization: The World Public Access UNIX, Brookline, MA Xref: archiver1.google.com comp.lang.ada:29672 Date: 2002-10-10T15:38:05+00:00 List-Id: prichtmyer@yahoo.com (Peter Richtmyer) writes: > This is a little on the light side, but is also > frustrating to see in "portable Ada". Perhaps others > with different compilers will find even different > results. I think the size of a null record should be zero bits, and the size of an array of zero-sized components should also be zero. But that's just my opinion -- the RM doesn't require it. I think the RM *does* require 'Size to be zero in these cases: subtype S is Integer range 10..9; -- S'Size = 0 type Enum is (Red); -- Enum'Size = 0 assuming the implementation claims to support the Systems Programming Annex. (Without the SP annex, there are almost *no* requirements on representation-related stuff.) This is true whether or not a "for ...'Size use 0;" is given. I'm curious: why do you care what the size of a null record is, or an array of them? It's rather unusual to create large numbers of null records! Note that 'Size of subtypes is almost meaningless, anyway. It really only affects the size of components of packed arrays and records. Your test would be more interesting if you declared some *objects*, and printed out the 'Size of those -- 'Size of objects is meaningful. I'd be interesting in seeing the results (and also what happens if one of the above S or Enum is used instead of the null record). The Aonix behavior (compiler crashes) is clearly a bug -- you should report it. (It's probably also an operating system bug -- crashing programs should not refuse to close. But I suspect it's a waste of time to report *that* bug. ;-) ) Whether the behavior of the other two is a bug or not is a matter of opinion. It's certainly not a nonconformity to the Standard. But it's a bug if you don't like it, and you have enough money to bribe the compiler vendor into fixing it. ;-) You're disconcerted by the non-portability, but note that there are many non-portabilities in chap 13. That's intentional -- it's important to give compilers plenty of freedom to use the target hardware in the most efficient way. (But I must admit, I don't know of any hardware that would have trouble representing zero-sized things.) Here's one issue: if you said "array ... of aliased nul;", then the compiler would pretty much *have* to make the components non-zero size, because aray(1)'Access must not equal aray(2)'Access. For the same reason, compilers generally don't allocate zero space for heap objects. > ----------------------------------------------------- > with Text_Io; > procedure nil is > type nul is null record; > for nul'size use 0; > nil : nul; > type aray is array (1 .. 1000) of nul; > -- pragma pack (aray); -- line 7 > -- for aray'size use 0; -- line 8 > ary : aray; > type dbl is array (1 .. 1000) of aray; > -- pragma pack (dbl); -- line 11 > -- for dbl'size use 0; -- line 12 > dub : dbl; > begin > text_io.put_line ("Nil size = " & integer'image(nil'size)); > text_io.put_line ("Ary size = " & integer'image(ary'size)); > text_io.put_line ("Dub size = " & integer'image(dub'size)); > -------------------------------------------- > -- output on Gnat 3.14p (win2000): > -- Nil size = 8 > -- Ary size = 8 > -- Dub size = 8 Are you implying that you got this output with the above lines *not* commented out? If that's the case, then it's clearly a bug -- if the compiler isn't going to give back 0, then it shouldn't let you specify 0 -- it must give a compile-time error. > -------------------------------------------- > -- Rational Apex Ada 95 v. 4.0.0b (Solaris) > -- (would not compile until I commented out lines 8 & 12) > -- 06:39:44 AM >>> Line 8: for Aray'Size use 0; > -- 06:39:44 AM *** Specified size 0 is too small for array (1 .. 1000) of Nul > -- 06:39:44 AM ++* nil.2.ada has failed to install in ... > -- 06:39:50 AM +++ 1 unit was parsed > -- 06:39:50 AM ++* 1 unit could not be installed > -- > -- Rational output with lines 8 & 12 commented out: > -- Nil size = 0 > -- Ary size = 1000 > -- Dub size = 1000000 > -------------------------------------------- > -- Aonix ObjectAda 7.1.105 Professional Version (win2000) > -- (Would not compile. Window said:) > -- Program Error > -- ADACOMP.exe has generated errors and will be closed by > -- Windows. You will need to restart the program. > -- An error log is being created. > -- It did not close. I could not find an error log. > -- In order to even start compiling, I had to comment lines 7,8,11,12 > -- Then output was: > -- Nil size = 0 > -- Ary size = 0 > -- Dub size = 0 > -- which is what I wanted! > --------------------------------------------- > > end nil; > > ----- > Don't know if there is a "right" result, or is this one of > those gray areas. Anybody? Gray area. - Bob