Zero length Objects

Zero length Objects

[Robert C. Leif]

I am trying to create a means to report the value of experimental
parameters.  I would like to store only those parameters that I have
selected.  Since thanks to Robert I. Eachus, I am using a variant record, I
can set the parameter to null, which is presently stored as 16 bits.  I
created an empty type; please see the small main procedure below. I have not
been able to have the size attribute work directly on null.

with Ada.Text_Io;
procedure Empty_Pkg is 
   package T_Io renames Ada.Text_Io;
   type Empty_Type is 
         (Empty); 
   for Empty_Type'Size use 0;
   Empty_Var : Empty_Type;  
begin
   T_Io.Put_Line("The size of empty is " & Integer'Image(Empty_Var'Size));

end Empty_Pkg;

This produced: The size of empty is 8

Thank you.
Bob Leif

Re: Zero length Objects

[Jacob Sparre Andersen]

Robert C. Leif wrote:

> I am trying to create a means to report the value of experimental
> parameters.  I would like to store only those parameters that I have
> selected.  Since thanks to Robert I. Eachus, I am using a variant
> record, I can set the parameter to null, which is presently stored
> as 16 bits.  I created an empty type; please see the small main
> procedure below. I have not been able to have the size attribute
> work directly on null.
> 
> with Ada.Text_Io;
> procedure Empty_Pkg is 
>    package T_Io renames Ada.Text_Io;
>    type Empty_Type is 
>          (Empty); 
>    for Empty_Type'Size use 0;
>    Empty_Var : Empty_Type;  
> begin
>    T_Io.Put_Line("The size of empty is " & Integer'Image(Empty_Var'Size));
> 
> end Empty_Pkg;
> 
> This produced: The size of empty is 8

I thought:

   type Even_Emptier_Type is null record;
   for Even_Emptier_Type'Size use 0;
   Even_Emptier_Var : Even_Emptier_Type;

might be more effective, but no, also the size of Even_Emptier_Var is 8. :(

Jacob
-- 
"Banning open source would have immediate, broad, and
 strongly negative impacts on the ability of many sensitive
 and security-focused DOD groups to protect themselves
 against cyberattacks"                        -- Mitre Corp.

Re: Zero length Objects

[Frank J. Lhota]

No object is really of zero length. The reason is that every object should
have a unique address. Therefore, most Ada compilers will allocate at least
one storage element to each object, in order to insure that if we declare

       A, B : Empty_Type;

then A and B do not both refer to the same location.

Re: Zero length Objects

[Nick Roberts]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message
news:PSFEc.50650$aJ3.17580@nwrdny02.gnilink.net...

> No object is really of zero length. The reason is that every object should
> have a unique address. Therefore, most Ada compilers will allocate at
least
> one storage element to each object, in order to insure that if we declare
>
>        A, B : Empty_Type;
>
> then A and B do not both refer to the same location.

Yes indeed. There was a long discussion about this in the Ada Comment list.
I hope Randy and Tucker are reading this thread, because it seems to add
fuel to my argument that the 'right' thing for a compiler to do is to allow
zero-size objects (and to perform zero-size allocation for them), and to
implement the access value mechanism I suggested.

For the curious, the mechanism I suggested was that the compiler 'invents'
unique encodings for access values that reference zero-size objects. An
invented encoding can be any value that can be stored in an object of the
access type which is guaranteed never to be the same as any valid address
(or other invented value in scope), assuming the typical mechanism that an
access value which references a nonzero-size object is simply its address.

This provides a way to preserve the 'uniqueness characteristic' of access
values, that if they designate different objects their values will be
different, without preventing the implementation of genuinely zero-size
objects (that do not take up any memory at all).

I believe the uniqueness characteristic of access values should be inviolate
(because certain algorithms might depend on it), and that genuinely
zero-size objects (actually, zero-size types) are sometimes useful (in
generic instantiations). Randy and Tucker disagreed (or at least, they
didn't agree that the uniqueness characteristic should be mandated by the
standard for access values referencing zero-size objects). I live in hope.

-- 
Nick Roberts

Re: Zero length Objects

[Brian May]

>>>>> "Frank" == Frank J Lhota <NOSPAM.lhota.adarose@verizon.net> writes:

    Frank> No object is really of zero length. The reason is that
    Frank> every object should have a unique address. Therefore, most
    Frank> Ada compilers will allocate at least one storage element to
    Frank> each object, in order to insure that if we declare

    Frank> A, B : Empty_Type;

    Frank> then A and B do not both refer to the same location.

Is there any reason every object needs to have a unique address?

I thought it would only be important for aliased objects or objects
allocated on the heap, as it isn't possible (AFAIK) to get the address
otherwise.

Not that I care either way ;-).
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Zero length Objects

[Georg Bauhaus]

Nick Roberts <nick.roberts@acm.org> wrote:
: "Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message
: news:PSFEc.50650$aJ3.17580@nwrdny02.gnilink.net...
: 
:> No object is really of zero length. The reason is that every object should
:> have a unique address. Therefore, most Ada compilers will allocate at
: least
:> one storage element to each object, in order to insure that if we declare
:>
:>        A, B : Empty_Type;
:>
:> then A and B do not both refer to the same location.
: 
: Yes indeed.

One might add that the full story has zero size things if not
objects:

with Ada.Text_IO;

procedure sz is
   type Nothing is null record;
   for Nothing'size use 0;

   type What is record
      thing: Natural := 1_000_000;
      more: Nothing;
   end record;

   type Then_Again is record
      uhm: Nothing;
   end record;

   package TIO renames Ada.Text_IO;

   x: What;
   y: Then_Again;
begin
   TIO.put_line("size of Natural: " & Natural'image(Natural'size));
   TIO.put_line("size of x of type What: " & Natural'image(x'size));
   TIO.put_line("size of y of type Then_Again: " & Natural'image(y'size));
end sz;

$ ./sz
size of Natural:  31
size of x of type What:  32
size of y of type Then_Again:  8
$

So the size of the .more component is no greater than 1, I think.


Georg

Re: Zero length Objects

[Björn Persson]

Georg Bauhaus wrote:

> So the size of the .more component is no greater than 1, I think.

Well, let's look:

size of Natural:  31
size of x of type What:  32
size of y of type Then_Again:  8
size of x.thing of type Natural:  32
size of x.more of type Nothing:  0
size of y.uhm of type Nothing:  0

(With GCC-Gnat 3.4.0.)

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Zero length Objects

[Larry Kilgallen]

In article <2kh2leF2ct4hU1@uni-berlin.de>, "Nick Roberts" <nick.roberts@acm.org> writes:

> For the curious, the mechanism I suggested was that the compiler 'invents'
> unique encodings for access values that reference zero-size objects. An
> invented encoding can be any value that can be stored in an object of the
> access type which is guaranteed never to be the same as any valid address
> (or other invented value in scope), assuming the typical mechanism that an
> access value which references a nonzero-size object is simply its address.

I don't understand how one can guarantee such non-conflicting encodings
are possible on all architectures, particular when the compiler supports
operating system programming in Ada.

Re: Zero length Objects

[Frank J. Lhota]

"Brian May" <bam@snoopy.apana.org.au> wrote in message
news:sa41xjwy2nv.fsf@snoopy.apana.org.au...
> >>>>> "Frank" == Frank J Lhota <NOSPAM.lhota.adarose@verizon.net> writes:
>
>     Frank> No object is really of zero length. The reason is that
>     Frank> every object should have a unique address. Therefore, most
>     Frank> Ada compilers will allocate at least one storage element to
>     Frank> each object, in order to insure that if we declare
>
>     Frank> A, B : Empty_Type;
>
>     Frank> then A and B do not both refer to the same location.
>
> Is there any reason every object needs to have a unique address?

The issue is that if A and B share an address, then they are basically
aliases of each other, for no subprogram could distinguish between them. The
programmer, however, is declaring A and B as two separate objects, so making
them aliases would be a violation of the author's intentions.

AFAIK C++ takes the same approach. In fact, the first C++ tutorial I went
through (the one that came with Borland's groundbreaking BC++ compiler for
DOS and Windows) included a code sample that was something like this:

    class CEmpty {};
    ...
    CEmpty a, b;

The tutorial recommended generating an assembly listing for this code to
note that even though CEmpty is empty, a and b are allocated at separate
addresses, and that this is important because operations should be able to
distinguish a and b. I tried this with GCC and MSVC. Not only did both
compilers assign a and b separate addresses, but for both of these compilers

    ( sizeof( CEmpty ) == 1 ) && ( sizeof( a ) == 1 )

Re: Zero length Objects

[Xenos]

"Nick Roberts" <nick.roberts@acm.org> wrote in message
news:2kh2leF2ct4hU1@uni-berlin.de...
> "Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message
> news:PSFEc.50650$aJ3.17580@nwrdny02.gnilink.net...
>
> > No object is really of zero length. The reason is that every object
should
> > have a unique address. Therefore, most Ada compilers will allocate at
> least
> > one storage element to each object, in order to insure that if we
declare
> >
> >        A, B : Empty_Type;
> >
> > then A and B do not both refer to the same location.
>
> Yes indeed. There was a long discussion about this in the Ada Comment
list.
> I hope Randy and Tucker are reading this thread, because it seems to add
> fuel to my argument that the 'right' thing for a compiler to do is to
allow
> zero-size objects (and to perform zero-size allocation for them), and to
> implement the access value mechanism I suggested.
>
> For the curious, the mechanism I suggested was that the compiler 'invents'
> unique encodings for access values that reference zero-size objects. An
> invented encoding can be any value that can be stored in an object of the
> access type which is guaranteed never to be the same as any valid address
> (or other invented value in scope), assuming the typical mechanism that an
> access value which references a nonzero-size object is simply its address.
>
> This provides a way to preserve the 'uniqueness characteristic' of access
> values, that if they designate different objects their values will be
> different, without preventing the implementation of genuinely zero-size
> objects (that do not take up any memory at all).
>
> I believe the uniqueness characteristic of access values should be
inviolate
> (because certain algorithms might depend on it), and that genuinely
> zero-size objects (actually, zero-size types) are sometimes useful (in
> generic instantiations). Randy and Tucker disagreed (or at least, they
> didn't agree that the uniqueness characteristic should be mandated by the
> standard for access values referencing zero-size objects). I live in hope.
>
> -- 
> Nick Roberts
>
>

C++ has a similar rule that says an object cannot be zero bytes in size, but
it does says that an empty (no data members) base class may be zero size
within the inherited class.  Does Ada have a similar rule to this?  Meaning
if I create a null record and derive a another record from it, will the null
record take up zero space within the derived record?  Sorry, if my
terminology isn't exact for Ada, I a little new to the 95 standard.

Re: Zero length Objects

[Nick Roberts]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:MmlhKUHhwSXB@eisner.encompasserve.org...

> I don't understand how one can guarantee such non-conflicting
> encodings are possible on all architectures, particular when the
> compiler supports operating system programming in Ada.

I'm pretty sure that such a scheme would be feasible for just about any
target architecture. Even if an address is a simple linear memory address
(with no special bits at all) one word in size, and access values are
implemented as such an unadorned address, there will be significant areas of
memory which are known to be suitably invalid addresses.

The fact that we are not talking about access-to-subprogram types helps. For
any access-to-object type implemented as above, any value which is an
address pointing at code is invalid for dereferencing, and so suitable as an
invented value to 'reference' an object of zero size. An easy algorithm for
allocating such invented values would be to start at the memory location at
the beginning of program code (which is typically all gathered in one lump
on such machines) and work upwards. A range check can be used to check
dereferencing of access values.

For many architectures, there will be some encoding of access values that
cannot be any valid address, or which could reasonably be interpreted that
way. For example, on any 64-bit architecture, I think it would be reasonable
to use bit 63 (the uppermost bit) to flag invented values. Typically, the
hardware will provide the necessary dereference checking; you only need to
ensure nothing is ever allocated to the upper half the address range.

I'd prefer the new revision of the standard (Ada 2005) to mandate the
semantics which seem to be implied (although arguably) by the wording in the
Ada 95 RM (unchanged in the TC in 2000), which is inherited almost unchanged
from the Ada 83 LRM. I'd be happy for an implementation permission to allow
the semantics to be dropped when (and only when) they cannot be reasonably
supported (but I'd expect such circumstances to be rare, in reality). Maybe
in the /next/ revision.

-- 
Nick Roberts

Re: Zero length Objects

[Nick Roberts]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message
news:2oUEc.2$S77.1@nwrdny03.gnilink.net...

> "Brian May" <bam@snoopy.apana.org.au> wrote in message
> news:sa41xjwy2nv.fsf@snoopy.apana.org.au...

> > Is there any reason every object needs to have a unique address?

> The issue is that if A and B share an address, then they are basically
> aliases of each other, for no subprogram could distinguish between
> them. The programmer, however, is declaring A and B as two
> separate objects, so making them aliases would be a violation of the
> author's intentions.

I understand that the C and C++ standards mandate that all types (classes)
must have a size greater than zero, for the reasons Frank gave. To expand on
on his example a little, supposing we wrote a general-purpose termplate
function which had to make sure its two parameters were not aliased:

   template <class C>
   function wibble(C* x, C* y) {
      if (x==y) raise Aliasing_Error;
      ...
   };

if we then had a class with no members:

   class CEmpty {
      ...
   };

   CEmpty a, b;

and tried to execute:

   wibble(&a,&b);

we would wrongly get Aliasing_Error raised if a and b had been allocated to
the same address. The rule that types (and so their objects) cannot be of
zero size prevents this happening.

To my mind, a significant problem remains. If we declared something like:

      CWhatever mem_a[1000000];

somewhere in a template class, where CWhatever was a template parameter, and
then instantiated the class with CEmpty replacing CWhatever, we would get a
mem_a in the instance that took up a whopping amount of memory to store
absolutely nada! Yuk.

PS: Please forgive any minor mistakes, I'm not a C++ expert.

-- 
Nick Roberts

Re: Zero length Objects

[Xenos]

"Nick Roberts" <nick.roberts@acm.org> wrote in message
news:2kimpdF2orakU1@uni-berlin.de...

> To my mind, a significant problem remains. If we declared something like:
>
>       CWhatever mem_a[1000000];
>
> somewhere in a template class, where CWhatever was a template parameter,
and
> then instantiated the class with CEmpty replacing CWhatever, we would get
a
> mem_a in the instance that took up a whopping amount of memory to store
> absolutely nada! Yuk.
>
> PS: Please forgive any minor mistakes, I'm not a C++ expert.
>
> -- 
> Nick Roberts
>
>

But C++ does compensate for this somewhat.  Empty base classes (used for
traits and the like) will not take any space in derived classes.  For
example:

class Empty {};

class Derived : public Empty {
   char a;
};

Derived D[1000000];

Here, Empty is not increase the size of D at all.

DrX

Re: Zero length Objects

[Nick Roberts]

"Xenos" <dont.spam.me@spamhate.com> wrote in message
news:cc15on$nsc5@cui1.lmms.lmco.com...

> C++ has a similar rule that says an object cannot be zero bytes in
> size, but it does says that an empty (no data members) base class
> may be zero size within the inherited class.  Does Ada have a
> similar rule to this?

As far as I am aware, the Ada standard permits types, subtypes, and objects
of zero size. I think that X'Size must return 0 if it has been set to 0 (by
a representation clause) for any subtype or object X, but there is nothing
in the standard to prevent objects of zero size being allocated more than
zero bits when they are allocated in memory (and I gather this is what many
compilers actually do).

> Meaning if I create a null record and derive a another record from it,
> will the null record take up zero space within the derived record?

Again, I don't think the standard mandates exactly what the comnpiler does
by default. However, of course, you can always /tell/ the compiler where and
how big a member should be (in a record representation clause). Oddly, you
can specify something like:

      Empty_Member at 0 range 1..0;

in order to tell the compiler that Empty_Member is to take up no space in
the record.

> Sorry, if my terminology isn't exact for Ada, I a little new to the 95
> standard.

I have the same problem with C++ :-)

-- 
Nick Roberts

Re: Zero length Objects

[Larry Kilgallen]

In article <2kikcvF2r8ikU1@uni-berlin.de>, "Nick Roberts" <nick.roberts@acm.org> writes:
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
> news:MmlhKUHhwSXB@eisner.encompasserve.org...
> 
>> I don't understand how one can guarantee such non-conflicting
>> encodings are possible on all architectures, particular when the
>> compiler supports operating system programming in Ada.
> 
> I'm pretty sure that such a scheme would be feasible for just about any
> target architecture. Even if an address is a simple linear memory address
> (with no special bits at all) one word in size, and access values are
> implemented as such an unadorned address, there will be significant areas of
> memory which are known to be suitably invalid addresses.
> 
> The fact that we are not talking about access-to-subprogram types helps. For

I did not realize that.

> any access-to-object type implemented as above, any value which is an
> address pointing at code is invalid for dereferencing, and so suitable as an
> invented value to 'reference' an object of zero size. An easy algorithm for
> allocating such invented values would be to start at the memory location at
> the beginning of program code (which is typically all gathered in one lump
> on such machines) and work upwards. A range check can be used to check
> dereferencing of access values.

On VMS program code is "typically" gathered together, but not "necessarily".

> For many architectures, there will be some encoding of access values that
> cannot be any valid address, or which could reasonably be interpreted that
> way. For example, on any 64-bit architecture, I think it would be reasonable
> to use bit 63 (the uppermost bit) to flag invented values. Typically, the
> hardware will provide the necessary dereference checking; you only need to
> ensure nothing is ever allocated to the upper half the address range.

But that really is the territory of the operating system (if any).
Today VMS does not use that range, but there is no commitment it will
not use it in the future.

Re: Zero length Objects

[Hyman Rosen]

Xenos wrote:
> But C++ does compensate for this somewhat.  Empty base classes (used for
> traits and the like) will not take any space in derived classes.  For
> example:
> 
> class Empty {};
> class Derived : public Empty { char a; };
> Derived D[1000000];
> 
> Here, Empty is not increase the size of D at all.

But it's more complicated than that, because C++ does have the
similar rule that no distinct objects of the same type can have
the same address. Expanding on your example,

     struct Empty1 { }; struct Empty2 { };
     struct Derived : Empty1, Empty2 { char a; };
     Derived D[1000000];

The optimization still applies, and sizeof(Derived)
can still be one. But do as follows:

     struct Empty { };
     struct E1 : Empty { }; struct E2 : Empty { };
     struct Derived : E1, E2 { char a; };
     Derived D[1000000];

Now, Derived has two distinct subobjects both of type
Empty. They cannot be allocated at the same address, so
it's likely that sizeof(Derived) is > 1. Although, in
this case the compiler can get really clever and place
one of the Empty objects before the char and one after.
But cases can be concocted where extra pad bytes are
definitely required to avoid messing up object identity.

Re: Zero length Objects

[Xenos]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1088697459.558708@master.nyc.kbcfp.com...
> Xenos wrote:
> > But C++ does compensate for this somewhat.  Empty base classes (used for
> > traits and the like) will not take any space in derived classes.  For
> > example:
> >
> > class Empty {};
> > class Derived : public Empty { char a; };
> > Derived D[1000000];
> >
> > Here, Empty is not increase the size of D at all.
>
> But it's more complicated than that, because C++ does have the
> similar rule that no distinct objects of the same type can have
> the same address. Expanding on your example,
>
>      struct Empty1 { }; struct Empty2 { };
>      struct Derived : Empty1, Empty2 { char a; };
>      Derived D[1000000];
>
> The optimization still applies, and sizeof(Derived)
> can still be one. But do as follows:
>
>      struct Empty { };
>      struct E1 : Empty { }; struct E2 : Empty { };
>      struct Derived : E1, E2 { char a; };
>      Derived D[1000000];
>
> Now, Derived has two distinct subobjects both of type
> Empty. They cannot be allocated at the same address, so
> it's likely that sizeof(Derived) is > 1. Although, in
> this case the compiler can get really clever and place
> one of the Empty objects before the char and one after.
> But cases can be concocted where extra pad bytes are
> definitely required to avoid messing up object identity.
>

Which is why I said "somewhat."

Re: Zero length Objects

[Jeffrey Carter]

Nick Roberts wrote:

> As far as I am aware, the Ada standard permits types, subtypes, and
> objects of zero size. I think that X'Size must return 0 if it has
> been set to 0 (by a representation clause) for any subtype or object
> X, but there is nothing in the standard to prevent objects of zero
> size being allocated more than zero bits when they are allocated in
> memory (and I gather this is what many compilers actually do).

The 'Size of an object need not be the same as the subtype 'Size. For
example, on many systems, Integer'Size = 32, Natural'Size = 31. For

N : Natural;

N'Size is usually 32. 31 comes into play in situations such as packed types.

Similarly, for

type Size_2 is (One, Two, Three, Four);
for Size_2'Size use 2;

S : Size_2;

S'Size is usually 8.

-- 
Jeff Carter
"I'm a lumberjack and I'm OK."
Monty Python's Flying Circus
54

Re: Zero length Objects

[Christoph Karl Walter Grein]

There are types needing no space, but objects cannot have zero size.
_______________________________________________________
WEB.DE Video-Mail - Sagen Sie mehr mit bewegten Bildern
Informationen unter: http://freemail.web.de/?mc=021199

Re: Zero length Objects

[Frank J. Lhota]

This is what I love about this NG. In the thread "A simple ADA puzzle", we
had an interesting and informative discussion of how a compiler should
handle a type whose objects may be billions of bytes long. Now in this
thread, we are having an equally enlightening discussion of types whose
objects are potentially zero bytes long. Looks like we have covered both
ends of the spectrum!

Re: Zero length Objects

[Adrian Knoth]

Frank J. Lhota <NOSPAM.lhota.adarose@verizon.net> wrote:

> This is what I love about this NG. In the thread "A simple ADA puzzle", we
> had an interesting and informative discussion of how a compiler should
> handle a type whose objects may be billions of bytes long. Now in this
> thread, we are having an equally enlightening discussion of types whose
> objects are potentially zero bytes long. Looks like we have covered both
> ends of the spectrum!

You missed objects with negative storage size, but I guess bufferoverflows
are offtopic in cla, otherwise it'd be called comp.lang.c.


-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Fighting for peace is like fucking for virginity!

Re: Zero length Objects

[Frank J. Lhota]

"Adrian Knoth" <adi@thur.de> wrote in message
news:slrnceaup5.t7n.adi@ppc201.mipool.uni-jena.de...
> You missed objects with negative storage size, but I guess bufferoverflows
> are offtopic in cla, otherwise it'd be called comp.lang.c.

If objects with negative storage size were supported, then I could declare

    Slack : String ( 1 .. -2_147_483_645 );

and get a big increase in available memory :)

Re: Zero length Objects

[Vinzent 'Gadget' Hoefler]

Frank J. Lhota wrote:

>If objects with negative storage size were supported, then I could declare
>
>    Slack : String ( 1 .. -2_147_483_645 );
>
>and get a big increase in available memory :)

There's an easier way which is already supported:

   One : String (1 .. 100_000);
   Two : String (1 .. 100_000);

   for Two'Address use One'Address;

And you've just halved your memory requirements.


Vin"Bye folks, and watch out for another lesson of 'How to shoot you
in the foot with Ada' next week in you favourite usenet channel."zent.

Re: Zero length Objects

[Adrian Knoth]

Vinzent 'Gadget' Hoefler <nntp-2004-07@t-domaingrabbing.de> wrote:
> Frank J. Lhota wrote:

>    One : String (1 .. 100_000);
>    Two : String (1 .. 100_000);
>    for Two'Address use One'Address;

As I've mentioned earlier in this thread we're not talking about C ;)


-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Anfrage in thur.markt: Suche ein Moped, S51 w�re am besten.
Antwort von Peter K�llner: Und? Hast du es gefunden?

Re: Zero length Objects

[Vinzent 'Gadget' Hoefler]

Adrian Knoth wrote:

>Vinzent 'Gadget' Hoefler <nntp-2004-07@t-domaingrabbing.de> wrote:
>
>>    One : String (1 .. 100_000);
>>    Two : String (1 .. 100_000);
>>    for Two'Address use One'Address;
>
>As I've mentioned earlier in this thread we're not talking about C ;)

Do *that* in portable C without using pointers and I will shut up. ;)


Vinzent.

Re: Zero length Objects

[Xenos]

>"Vinzent 'Gadget' Hoefler" <nntp-2004-07@t-domaingrabbing.de> wrote in
message >news:d4dbe092us62t56f99fcoucn4bjukc6v4a@jellix.jlfencey.com...
>Adrian Knoth wrote:

>>Vinzent 'Gadget' Hoefler <nntp-2004-07@t-domaingrabbing.de> wrote:
>>
>>>    One : String (1 .. 100_000);
>>>    Two : String (1 .. 100_000);
>>>    for Two'Address use One'Address;
>>
>>As I've mentioned earlier in this thread we're not talking about C ;)
>
>Do *that* in portable C without using pointers and I will shut up. ;)
>
>Vinzent.

union X {
    char a[100000];
    char b[100000];
} x;


DrX

Re: Zero length Objects

[Vinzent 'Gadget' Hoefler]

Xenos wrote:

>>"Vinzent 'Gadget' Hoefler" <nntp-2004-07@t-domaingrabbing.de> wrote in
>message >news:d4dbe092us62t56f99fcoucn4bjukc6v4a@jellix.jlfencey.com...
>
>>>Vinzent 'Gadget' Hoefler <nntp-2004-07@t-domaingrabbing.de> wrote:
>>>
>>>>    One : String (1 .. 100_000);
>>>>    Two : String (1 .. 100_000);
>>>>    for Two'Address use One'Address;
[...]
>>
>>Do *that* in portable C without using pointers and I will shut up. ;)
>
>union X {
>    char a[100000];
>    char b[100000];
>} x;

Ok. Mouth is closed. :)

Re: Zero length Objects

[Nick Roberts]

On Fri, 02 Jul 2004 10:30:18 +0200, Christoph Karl Walter Grein  
<AdaMagica@web.de> wrote:

> There are types needing no space, but objects cannot have zero size.

I don't want to go round in circles, but I think the situation can be  
summarised thus:

* In C and C++, a member of a struct or class can be of zero size, but  
otherwise an object (variable or constant) cannot be of zero size  
(allocated no space in memory).

* In Ada, any object can be of zero size (allocated no space), except that  
if an aliased object has zero size, and there is an access value  
referencing it, either the access value might not be distinguishable from  
an access value referencing another object, or the compiler must implement  
special code to enable such access values to be distinguished.

Some Ada compilers avoid the above problem by making all aliased objects  
of a zero size subtype have a nonzero (allocated) size. I'm in favour of  
the special code.

Some Ada compilers simply ignore the problem (permitting access values to  
be indistinguishable). It is my contention (and I think I have some  
support for it :-) that this contravenes the RM 95, although this is being  
pedantic.

I think the majority of the ARG are going to fix the wording in the RM  
2005 to allow an implementation's access values to compare equal if they  
designate different objects one of which is of zero size (or both are),  
provided neither access value is null (they /must/ compare equal if they  
are both null). Personally, I disagree with this fix.

-- 
Nick Roberts

Re: Zero length Objects

[Randy Brukardt]

"Nick Roberts" <nick.roberts@acm.org> wrote in message
news:opsapswqnop4pfvb@bram-2...
...
> I think the majority of the ARG are going to fix the wording in the RM
> 2005 to allow an implementation's access values to compare equal if they
> designate different objects one of which is of zero size (or both are),
> provided neither access value is null (they /must/ compare equal if they
> are both null). Personally, I disagree with this fix.

The ARG does not even have a consensus whether this "issue" should even be
on the agenda, or whether it is a pathology that is not worth spending time
on. It is unlikely that the ARG would come to some conclusion in time to
include it in the Amendment.

                     Randy Brukardt

Re: Zero length Objects

[Nick Roberts]

On Tue, 6 Jul 2004 17:14:35 -0500, Randy Brukardt <randy@rrsoftware.com>  
wrote:

> The ARG does not even have a consensus whether this "issue" should
> even be on the agenda, or whether it is a pathology that is not
> worth spending time on. It is unlikely that the ARG would come to
> some conclusion in time to include it in the Amendment.

Sorry, my memory is not reliable enough.

(I need to upgrade to 4-bit ECC :-)

-- 
Nick Roberts