zero sized structures 
Author Message
 zero sized structures

Hello !

hopefully this question sounds not too crazy.

what what's about empty structures in standard C
i.e.

typedef struct
{

Quote:
} empty_t;

thank you for your response !

--
Greetings from Lake Constance, Germany




Fri, 25 Jul 2003 04:16:00 GMT  
 zero sized structures

Quote:
>what what's about empty structures in standard C

>typedef struct
>{
>} empty_t;

AFAIK, at last in C90, it's a syntax error.

 Compiling MAIN.C:
 Error MAIN.C 3: Size of the type is unknown or zero

Compiling: main.c
main.c(3) Warning:  struct has no members
no errors

Huh! My compilers seems to have a different opinion about that.

I am sure one of the Guardians will find a more scholastic explanation.

Additionaly, I failed to understand how such an animal could be useful.

--
-hs-    Tabs out, spaces in.
CLC-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
ISO-C Library: http://www.dinkum.com/htm_cl
FAQ de FCLC : http://www.isty-info.uvsq.fr/~rumeau/fclc



Fri, 25 Jul 2003 04:44:30 GMT  
 zero sized structures

Quote:

>what what's about empty structures in standard C
>i.e.

>typedef struct
>{
>} empty_t;

Both the grammar in K&R2 and the one in n869 (neither of which define
the language, but they're both reasonable approximations to one of the
Standards that do define the language) require (if I'm reading them
correctly) at least one structure element, so an empty struct would be
an error.

gcc -ansi -pedantic also complains about a struct with no members.

dave

--

Quote:
> Oh how I hate the McVoidmain's! Almost as much as the MacAstmallocs.

Oh dear. I can't help thinking the OP has a point. :-)    --Mark A. Odell and
      Richard Heathfield comment on CLC being called `a bunch of sad tossers'


Fri, 25 Jul 2003 05:57:52 GMT  
 zero sized structures

Quote:


> >what what's about empty structures in standard C

> >typedef struct
> >{
> >} empty_t;

> AFAIK, at last in C90, it's a syntax error.

>  Compiling MAIN.C:
>  Error MAIN.C 3: Size of the type is unknown or zero

> Compiling: main.c
> main.c(3) Warning:  struct has no members
> no errors

> Huh! My compilers seems to have a different opinion about that.

Strange, when I was doing the parsing manually, from the information in K&R2
on p.212, my brain detected a syntax error. I got a problem with
"struct-declarator" missing.

Quote:
> I am sure one of the Guardians will find a more scholastic explanation.

Yepp, just wait and see.

Quote:
> Additionaly, I failed to understand how such an animal could be useful.

I guess not all animals are useful, at least a struct without any members,
is completely useless AFAIK.

--
Tor <torust AT online DOT no>



Fri, 25 Jul 2003 06:52:23 GMT  
 zero sized structures

Quote:



>> >what what's about empty structures in standard C

>> >typedef struct
>> >{
>> >} empty_t;

[ snip ]

Quote:
>> Additionaly, I failed to understand how such an animal could be useful.

>I guess not all animals are useful, at least a struct without any members,
>is completely useless AFAIK.

I can imagine how it might be convenient for machine-generated code,
like that produced by yacc.  That way, if you are using a struct to
hold some static set with user-specified members, you don't have to
consider the empty set as a special case.


Fri, 25 Jul 2003 07:06:25 GMT  
 zero sized structures

Quote:

> Hello !

> hopefully this question sounds not too crazy.

> what what's about empty structures in standard C
> i.e.

> typedef struct
> {
> } empty_t;

at least, thanks all for the good response.

I see you would hear whats about such a grazy construct.

I have C code like this

typedef struct
{
  person_t parent;
  int customer_id;

Quote:
} customer_t;

if I write this code I know that my parent is
of type person_t. but the implementation of person_t
may be don't need any instance variables.
anyway, if, for example, today's implementation
of person_t don't need any instance variable this might
will change in future. but the designer of parent_t don't
know how many children would implement himself nor does
he like to change all structures which are 'subtypes'. so
I think that it is the best to implement this behavior
in this way.

but if such a construct isn't well defined a possible solution
could be a combination of #define and #ifdef

does anybody have any ideas ?

thanks

Andreas
--
Greetings from Lake Constance, Germany




Fri, 25 Jul 2003 07:44:59 GMT  
 zero sized structures

Quote:



> >> Additionaly, I failed to understand how such an animal could be useful.

> >I guess not all animals are useful, at least a struct without any
members,
> >is completely useless AFAIK.

> I can imagine how it might be convenient for machine-generated code,
> like that produced by yacc.  That way, if you are using a struct to
> hold some static set with user-specified members, you don't have to
> consider the empty set as a special case.

Writing a parser is quite a complex task, but I can't see how an empty
struct will help you. IIRC, the struct generation will at some point
typically involve traversing a list. The case of an empty list is trivial,
see i.e. "Compiler design in C" by Allen I. Holub.

--
Tor <torust AT online DOT no>



Fri, 25 Jul 2003 07:54:43 GMT  
 zero sized structures

Quote:

> Additionaly, I failed to understand how such an animal could be useful.

typedef struct
{
#ifdef DO_SOME_STUFF
        int some_stuff;
#endif
#ifdef DO_SOME_MORE_STUFF
        int some_more_stuff;
#endif

Quote:
} message_t;

/* ... */

message_t *msg;
msg=malloc(sizeof *msg);  /* May return NULL if (sizeof *msg) is zero. */

#ifdef DO_SOME_STUFF
/* initialise msg->some_stuff */
#endif
#ifdef DO_SOME_MORE_STUFF
/* initailise msg->some_more_stuff */
#endif

As it stands, if neither DO_SOME_STUFF nor DO_SOME_MORE_STUFF is
wanted at compile time, message_t will become an empty struct, and
pointers to it would be thrown around.

Since empty structs are not allowed...

#if defined(DO_SOME_STUFF) || defined(DO_SOME_MORE_STUFF)
typedef struct
/* ... */
#else
typedef void message_t;
#endif

Alternatively...

typedef struct
{
   int not_used;
#ifdef /* ... */
#endif

Quote:
} message_t;

Bill, left an empty space.


Fri, 25 Jul 2003 17:08:27 GMT  
 zero sized structures


Quote:
>As it stands, if neither DO_SOME_STUFF nor DO_SOME_MORE_STUFF is
>wanted at compile time, message_t will become an empty struct, and
>pointers to it would be thrown around.

>Since empty structs are not allowed...

[snippage]

Back in the 1980s, when the C89 standard was being debated, there
was some brief talk about "zero sized objects".  Doug Gwyn offered
to head a sub-committee to define the properties of such objects.
Apparently no one took up the offer, and zero-sized objects were
eventually made illegal by fiat.

I think this is wrongheaded, but then, I do not get to decide what
is Proper C. :-)
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc




Fri, 25 Jul 2003 17:52:55 GMT  
 zero sized structures

Quote:



>>As it stands, if neither DO_SOME_STUFF nor DO_SOME_MORE_STUFF is
>>wanted at compile time, message_t will become an empty struct, and
>>pointers to it would be thrown around.

>>Since empty structs are not allowed...
>[snippage]

>Back in the 1980s, when the C89 standard was being debated, there
>was some brief talk about "zero sized objects".  Doug Gwyn offered
>to head a sub-committee to define the properties of such objects.
>Apparently no one took up the offer, and zero-sized objects were
>eventually made illegal by fiat.

Not *quite* true.

In J.2, n869 says:

    The behavior is undefined in the following circumstances:

    [...]

    A non-null pointer returned by a call to the calloc,
    malloc, or realloc function with a zero requested size
    is used to access an object (7.20.3).

This suggests to me that malloc(0U) is valid, and returns (or may
return) a non-null pointer - that cannot be used for anything except a
call to realloc() or free().

In effect, this would be a pointer to a zero-sized object.

Quote:
>I think this is wrongheaded, but then, I do not get to decide what
>is Proper C. :-)



Sat, 26 Jul 2003 10:15:41 GMT  
 zero sized structures


Quote:
>>Apparently no one took up the offer, and zero-sized objects were
>>eventually made illegal by fiat.

>Not *quite* true.

>In J.2, n869 says:

>    The behavior is undefined in the following circumstances:

>    [...]

>    A non-null pointer returned by a call to the calloc,
>    malloc, or realloc function with a zero requested size
>    is used to access an object (7.20.3).

>This suggests to me that malloc(0U) is valid, and returns (or may
>return) a non-null pointer - that cannot be used for anything except a
>call to realloc() or free().

>In effect, this would be a pointer to a zero-sized object.

The effect is the same, but it does not show that any zero-sized
objects exist.

The most obvious problem is that malloc(0) *can* just return NULL
every time.  In this case, that last clause never fires.

The next problem is harder to describe without resorting to
implementation details.  In order for malloc(0) to return a
"unique" pointer (as C89 called it), by far the easiest thing
to do in an implementation is:

        void *malloc(size_t size) {
                if (size < SOME_MINIMUM)
                        size = SOME_MINIMUM;
                ... now do the work ...
        }

In this case, as long as SOME_MINIMUM is at least 1, there is
in fact at least one accessible byte behind such a pointer.
Whether that byte is an "object" depends on your point of view,
of course. :-)

Ultimately this is all comp.std.c-like hairsplitting.  As for
myself, I would be happier with real, actual zero-sized objects,
with rules like "&A may compare equal to &B whenever either A or
B is a zero-sized object" (note that this is a large semantic
change to C!).
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc




Sat, 26 Jul 2003 10:40:58 GMT  
 zero sized structures

Quote:



>>>Apparently no one took up the offer, and zero-sized objects were
>>>eventually made illegal by fiat.

>>Not *quite* true.

>>In J.2, n869 says:

>>    The behavior is undefined in the following circumstances:

>>    [...]

>>    A non-null pointer returned by a call to the calloc,
>>    malloc, or realloc function with a zero requested size
>>    is used to access an object (7.20.3).

>>This suggests to me that malloc(0U) is valid, and returns (or may
>>return) a non-null pointer - that cannot be used for anything except a
>>call to realloc() or free().

>>In effect, this would be a pointer to a zero-sized object.

>The effect is the same, but it does not show that any zero-sized
>objects exist.

>The most obvious problem is that malloc(0) *can* just return NULL
>every time.  In this case, that last clause never fires.

>The next problem is harder to describe without resorting to
>implementation details.  In order for malloc(0) to return a
>"unique" pointer (as C89 called it), by far the easiest thing
>to do in an implementation is:

>        void *malloc(size_t size) {
>                if (size < SOME_MINIMUM)
>                        size = SOME_MINIMUM;
>                ... now do the work ...
>        }

The Standard does not mandate that an implementation must (or must not)
do it that way.

In fact, at least one implementation creates a linked list on the heap,
so pointers are guaranteed to be unique even for zero-sized objects
because of the internal, hidden "next" pointer.

Quote:
>In this case, as long as SOME_MINIMUM is at least 1, there is
>in fact at least one accessible byte behind such a pointer.

No!

If you access what lies behind the pointer *the behaviour is undefined*.
Whatever you might think your implementation does or does not do is
irrelevant.  There is a partay in your nose and every demon's invited.

Quote:
>Whether that byte is an "object" depends on your point of view,
>of course. :-)

But as far as *the Standard* is concerned, the object effectively has
zero length.

Quote:
>Ultimately this is all comp.std.c-like hairsplitting.  As for
>myself, I would be happier with real, actual zero-sized objects,
>with rules like "&A may compare equal to &B whenever either A or
>B is a zero-sized object" (note that this is a large semantic
>change to C!).

Making big changes to the language for small syntactic payoffs strikes
me as a very Bad Thing.


Sat, 26 Jul 2003 10:51:31 GMT  
 zero sized structures

Quote:


>Ultimately this is all comp.std.c-like hairsplitting.  As for
>myself, I would be happier with real, actual zero-sized objects,
>with rules like "&A may compare equal to &B whenever either A or
>B is a zero-sized object" (note that this is a large semantic
>change to C!).

Wow!  That's radical.  Just for reference, C++ says that a struct may
have no members and that such a object has non-zero size (Section 9/3).


Sat, 26 Jul 2003 11:25:04 GMT  
 
 [ 27 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Find size of variable size structure?

2. comparing two structures with memcmp after zeroing out?

3. Zero initialisation of structures

4. origin of declaring array of size zero

5. file size obtained by fstat() is always ZERO!!

6. Zero-sized array causes memory leaks?

7. zero-sized array in struct/union

8. Delete of zero-sized array of objects crashes

9. Page Size is Zero from CPrintDlg and CPageSetupDlg

10. copy constructors when size is zero

11. use of zero-sized array in struct/union?

12. zero/negative zero??

 

 
Powered by phpBB® Forum Software