Re: RFC: attribute "unpadded" (cf flexible array members)

[Erik Schnetter <schnetter at uni-tuebingen dot de>]

On ,30 Aug 2002 08:58:00 +0200 kaih at khms dot westfalen dot de (Kai Henningsen) wrote:
> So then it seems to me that a reasonably sane model of this for C would be  
> to make an unpadded type be similar to an incomplete type, *except* that  
> it can be used as a structure field (and possibly that we can dereference  
> its fields from a pointer to it).
>
> Can't use it to construct a variable or an array, same as you can't with  
> an incomplete type. Can have pointers to it as long as you don't try  
> pointer arithmetic, but again that should be the same as with an  
> incomplete type.
>
> Incomplete types can't sizeof(); no idea if it would be wiser to allow or  
> forbid this for unpadded types.
>
> Summary: an unpadded struct type is the same as an incomplete struct type,  
> except there are a very few things more that can be done with it (and that  
> can easily be enumerated in the docs) - *not* a complete struct type with  
> a number of hard-to-predict things that you can't do with it.

There might be a precedent where a struct type in ANSI C99 has a size
which is not a multiple of its alignment, namely a struct with a flexible
array member.  See http://gcc.gnu.org/ml/gcc/2002-05/msg02844.html.  It
seems that Mark's unpadded types and structs with flexible array members
have something in common.  If so, they should be treated similarly.

-erik

-- 
Erik Schnetter <schnetter@uni-tuebingen.de>
Web: http://www.tat.physik.uni-tuebingen.de/~schnette/

My email is as private as my paper mail.  I therefore support encrypting
and signing email messages.  Tell me if I can encrypt messages to you.
(For more information, go e.g. to http://www.pgpi.org.)