🚀 go-pugleaf

Paul Long (plong@perf.com) wrote:
: Regarding your response, one could argue that, even though the object
: has static storage duration, because the object has incomplete type,
: there are no members to initialize; therefore, "the size is not needed."

I realise you are only putting this forward as a possible argument,
but it seems very weak to me. An incomplete type _does_ have members,
you just don't know what they are. In another compilation unit you
probably do know what they are.

: Specifically, the Standard says in 6.5.7, "The type of the entity to be
: initialized shall be an object type or an array of unknown size." My
: example is neither--it is an incomplete type, so it is not "initialized
: implicitly" (also from section 6.5.7).

It is not initialised implicitly, because you don't get that far. 
You are not allowed to define a variable (or declare a static variable)
with an incomplete type (but see my next paragraph).

: This is not necessarily my position. though. I'm just trying to find in
: the Standard exactly what I'm supposed to do as an implementor.

I don't know of anywhere where it is spelled out (I find it very
difficult to find real information in the standard on incomplete/
opaque types), but I would suggest that you need the size to:

1) Do a sizeof (obviously)
2) Declare an automatic variable with the type (or an array of the type)
3) Declare a static/global variable with the type (or an array of the type)
4) Do pointer maths on a pointer to the type
5) Embed the type in another type.

I'm not quite sure about 5), but the others seem obvious to me. They
also fit with my experience in developing a fairly large software
system on various flavours on Unix using a lot of incomplete/opaque
types.

One thing I'd like to be able to do, but can't (tested with gcc)
is to have a header file with the following:


   /*
    * Erik's semi-complete types suggestion
    */

   /* This struct is unknown outside the library */

   typedef struct private_part_s private_part;

   /* This struct is known outside the library and (together with
    * the functions) describes the interface to the library
    */

   typedef struct public_part_s
   {
     int x;
     int y;
   } public_part;

   /*
    * This struct is semi-complete, ie. it is incomplete, but you
    * can do '->pub' on a pointer to it.
    */

   typedef struct my_object_s
   {
     public_part  pub;
     private_part priv;      /* fails with incomplete type error */
   } my_object;
   
What I'd like is for my_object to be a semi-complete type, where
the size is unknown (so the whole fragile base 'class' problem is
avoided), but a few of the elements are accessible (these could
also be function pointers). This enables you to specify library
interfaces which have a lot of OO features and are robust in terms of
binary compatibility (since the size of the object cannot be used
by the client code, the library implementer is never prevented from
expanding the structure/interface).

I recall (with a shudder) the man page for some terminal ioctls
where there were three different versions of the function and
the associated parameter structure to accommodate expansions of the
structure. Another problem call is the 'stat' family, where there
are several related functions, each with a slightly expanded
'struct stat' on some Unixes. This sort of thing could be handled in a
much nicer way with semi-complete types. I was very disappointed
when I found out that this is not what the 'private' and 'public'
keywords do in C++ (though there are good reasons for that).

Obviously, all public elements in the structure must precede all
incomplete elements, so that you know what offsets to look at
when using '->'.

-- 
You couldn't deny that, even if you tried with both hands. -- The Red Queen
--
Erik Corry ehcorry@inet.uni-c.dk