Null Record is not always Null

Null Record is not always Null

[Peter Richtmyer]

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.
-----------------------------------------------------
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
   --------------------------------------------
   -- 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?

Peter

Re: Null Record is not always Null

[Colin Paul Gloster]

Peter Richtmyer posted different behavior on three compilers and said:
"Don't know if there is a "right" result, or is this one of 
those gray areas. Anybody?"

Well, though 13.12 re pragmas has:

"[..]

An implementation may place limitations on the values of the expression
that are supported, and limitations on the supported combinations of
restrictions. The
consequences of violating such limitations are implementation defined.

[..]",

a pragma should never stop a compilation.

As for the rest, clearly you were given suboptimal results for your
possibly wacky null record but compilers are allowed to ignore your
requests:

"[..]

[..] A representation or operational item that is not supported by the
implementation is illegal, [..]

[..]

An implementation may interpret aspects of representation in an
implementation-defined manner. An implementation may place
implementation-defined restrictions
on representation items. [..]" (13.1).

In 13.3 is "nonnegative" chosen to denote >0 or >=0?

"[..]

Size may be specified for stand-alone objects via an
attribute_definition_clause; the expression of such a clause shall be
static and its value nonnegative.

[..]"

Re: Null Record is not always Null

[Robert A Duff]

Colin_Paul_Gloster@ACM.org (Colin Paul Gloster) writes:

> Peter Richtmyer posted different behavior on three compilers and said:
> "Don't know if there is a "right" result, or is this one of 
> those gray areas. Anybody?"
> 
> Well, though 13.12 re pragmas has:
> 
> "[..]
> 
> An implementation may place limitations on the values of the expression
> that are supported, and limitations on the supported combinations of
> restrictions. The
> consequences of violating such limitations are implementation defined.

13.12 is not talking about pragmas in general.  It is talking about
pragma Restrictions, so this quote is irrelevant.

> a pragma should never stop a compilation.

Right -- compilers should never crash.

> As for the rest, clearly you were given suboptimal results for your
> possibly wacky null record but compilers are allowed to ignore your
> requests:
> 
> "[..]
> 
> [..] A representation or operational item that is not supported by the
> implementation is illegal, [..]
> 
> An implementation may interpret aspects of representation in an
> implementation-defined manner. An implementation may place
> implementation-defined restrictions
> on representation items. [..]" (13.1).

Yes, but you also have to look at all the "Recommended Levels of
Support" (which are *requirements* if the compiler supports the SP
annex), and see if it talks about 'Size of null records.  It doesn't,
but it does talk about 'Size of things like "range 0..-1".

> In 13.3 is "nonnegative" chosen to denote >0 or >=0?

Zero is not negative.
But it's pretty close.  ;-)

By the way, it would be helpful if you specified paragraph numbers when
referring to the RM, as in 13.3(48) for this paragraph:

> "[..]
> 
> Size may be specified for stand-alone objects via an
> attribute_definition_clause; the expression of such a clause shall be
> static and its value nonnegative.
> 
> [..]"

So this means that a compiler cannot support "for T'Size use -1;",
but it *can* support "for T'Size use 0;".  You have to look at the
Recommended Levels of Support to see whether it's *required* to support
"... use 0".

- Bob

Re: Null Record is not always Null

[Colin Paul Gloster]

Robert A Duff wrote responding to Colin Paul Gloster:

"13.12 is not talking about pragmas in general.  It is talking about
pragma Restrictions, so this quote is irrelevant."

Sorry.

"By the way, it would be helpful if you specified paragraph numbers when
referring to the RM, as in 13.3(48) [..]"

I agree, but the HTML version on the Ada Information Clearinghouse
website does not provide the numbering (and I do not always feel like
counting manually) and I often do not have my Springer Verlag hardcopy
with me when I post to the newsgroup.

Re: Null Record is not always Null

[Robert A Duff]

Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> writes:

> I agree, but the HTML version on the Ada Information Clearinghouse
> website does not provide the numbering ...

I use the plain ascii text version, which has the advantage of being
able to cut-and-paste rules from the RM into posts and e-mail messages.

I'm surprised the HTML version has no paragraph numbers.
I consider an Ada RM without paragraph numbers to be useless.

The actual ISO Ada standard does not have paragraph numbers -- it's
against the ISO Standard for writing standards.  So when I produced the
final version, I produced one for ISO without paragraph numbers, and one
for everybody else with paragraph numbers.

>...(and I do not always feel like
> counting manually)

And if you *did* count manually, I'll bet you'd get the wrong answer in
some cases.  ;-)  The algorithm for determining the paragraph numbers is
arcane -- I never fully understood it.  There are several places where
there are paragraph numbers next to blank space, or the numbering starts
at 2.  And in the new version with the Corrigendum included, there are
cases like E.2.2(9.3).

- Bob

Re: Null Record is not always Null

[Randy Brukardt]

Colin Paul Gloster wrote in message <3DA5AE77.BE340477@ACM.org>...
>Robert A Duff wrote responding to Colin Paul Gloster:
>
>"By the way, it would be helpful if you specified paragraph numbers
when
>referring to the RM, as in 13.3(48) [..]"
>
>I agree, but the HTML version on the Ada Information Clearinghouse
>website does not provide the numbering (and I do not always feel like
>counting manually) and I often do not have my Springer Verlag hardcopy
>with me when I post to the newsgroup.

Wrong; the HTML RM on the AdaIC site does have paragraph numbers. I
spent a lot of time making the paragraph numbers look right in the HTML.
However, some versions of Netscape don't display my carefully crafted
work. (This is standard CSS1 markups.) Other versions of Netscape (and
all versions of IE that I've tried) display them fine.

       Randy Brukardt
       ARG Editor

Re: Null Record is not always Null

[Robert A Duff]

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

Re: Null Record is not always Null

[Peter Richtmyer]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccn0pmpan6.fsf@shell01.TheWorld.com>...

> 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!
> 
Thought somebody might ask. I am passing two structures (types) as 
generic parameters to a generic package. For some instantiations of the 
generic, one of the structures could be "null" - and I wanted to be 
able to test for null by testing the T'size of that structure 
in the generic package. But for portability I will probably pass a 
separate numeric "type_T_size" parameter so I do not need to rely on T'size
being zero when it is null.

There was really no practical reason to create arrays of the null
record type, I was just curious.   :-)    or is it   :-?

> 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.
> 
My mistake - I meant to include the program without any lines commented 
out. I got those results from Gnat with all source code "active". I think
it is a Gnat bug, but I am only running with the freebie Gnat right now.

thanks all,
Peter