views:

199

answers:

5

I'm integrating some code into my library. It is a complex data structure well optimized for speed, so i'm trying not to modify it too much. The integration process goes well and actually is almost finished (it compiles). One thing is still bothering me. I'm getting the C4200 warning multiple times:

warning C4200: nonstandard extension used : zero-sized array in struct/union
Cannot generate copy-ctor or copy-assignment operator when UDT contains a zero-sized array

The code works but this warning gives me creeps (especially the part with copy-ctor). THe warning appears because of structures declared like this:

#pragma pack( push )
#pragma pack( 1 )
// String
struct MY_TREEDATSTR
{
    BYTE btLen;
    DWORD dwModOff;
    BYTE btPat[0];
};

typedef MY_TREEDATSTR TREEDATSTR;
typedef MY_TREEDATSTR *PTREEDATSTR;

#pragma pack( pop )

Note the btPat[0]. Is there a way how to easily and correctly get rid of this warning without breaking the code and/or having to change too much in it. Notice the #pragma's, have their any significance according to this warning? And why is the structure declared this way anyway? (I mean the btPat thing, not the #pragma's, those i understand).

Note: i saw this similar question, but it really didn't help me.

Update: as I said, the code works and gives correct results. So a copy-constructor or assignment operator is apparently really not needed. And as i look at the code, none of the structures get memcpy-ed.

+2  A: 

If this is a MSVC compiler (which is what the warning message tells me), then you can disable this warning using #pragma warning, ie.:

#pragma warning( push )
#pragma warning( disable : 4200 )
struct _TREEDATSTR
{
    BYTE btLen;
    DWORD dwModOff;
    BYTE btPat[0];
};
#pragma warning( pop )

BTW, the message about the copy-constructor is not creepy, but a good thing because it means, that you can't copy instances of _TREEDATSTR without the unknown bytes in btPat: The compiler has no idea how big _TREEDATSTR really is (because of the 0-size array) and therefore refuses to generate a copy constructor. This means, that you can't do this:

_TREEDATSTR x=y;

which shouldn't work anyway.

Luther Blissett
Chances are that a copy constructor or copy-assignment operator is not needed anyway, a "C-style dynamically-sized struct" like this one is usually copied with `memcpy` etc.
dreamlax
+1  A: 

Try changing it to say btPat[1] instead. I think both C++ and C standards dictate that an array cannot have 0 elements. It could cause problems for any code that rely on the size of the _TREEDATSTR struct itself, but usually these sorts of structs are typecast from buffers where (in this case) the first byte of the buffer determines how many bytes are actually in btPat. This kind of approach relies on the fact that there is no bounds checking on C arrays.

dreamlax
To be precise, according to the standard, only array not allocated on the heap cannot have zero elements: int NotStandard[0]; int * Standard = new int[0];
Francesco
+5  A: 

I'll assume that you do want this to be compiled in pure C++ mode, and that you don't want just to compile some files in C and some in C++ and later link.

The warning is telling you that the compiler generated copy constructor and assignment will most probably be wrong with your structure. Using zero-sized arrays at the end of a struct is usually a way of having an array that is decided at runtime:

struct runtime_array {
   int size;
   char data[0];
};
runtime_array* create( int size ) {
   runtime_array *a = malloc( sizeof(runtime_array) + size );
   a->size = size;
   return a;
}
int main() {
   runtime_array *a = create( 10 );
   for ( int i = 0; i < a->size; ++i ) {
      a->data[i] = 0;
   }
   free(a);
}

This type of structures are meant to be allocated dynamically --or with dynamic stack allocation trickery--, and are not usually copied, but if you tried you would get weird results:

int main() {
   runtime_array *a = create(10);
   runtime_array b = *a;          // ouch!!
   free(a);
}

In this example the compiler generated copy constructor would allocate exactly sizeof(runtime_array) bytes in the stack and then copy the first part of the array into b. The problem is that b has a size field saying 10 but has no memory for any element at all.

If you still want to be able to compile this in C, then you must resolve the warning by closing your eyes: silent that specific warning. If you only need C++ compatibility, you can manually disable copy construction and assignment:

struct runtime_array {
   int size;
   char data[10];
private:
   runtime_array( runtime_array const & );            // undefined
   runtime_array& operator=( runtime_array const & ); // undefined
};

By declaring the copy constructor and assignment operator the compiler will not generate one for you (and won´t complain about it not knowing how). By having the two private you will get compile time errors if by mistake you try to use it in code. Since they are never called, they can be left undefined --this is also used to avoid calling it from within a different method of the class, but I assume that there are no other methods.

Since you are refactoring to C++, I would also make the default constructor private and provide a static public inlined method that will take care of the proper allocation of the contents. If you also make the destructor private you can make sure that user code does not try to call delete on your objects:

struct runtime_array {
   int size;
   char data[10];
   static runtime_array* create( int size ) {
      runtime_array* tmp = (runtime_array*)malloc(sizeof(runtime_array)+size);
      tmp->size = size;
      return tmp;
   }
   static void release( runtime_array * a ) {
      free(a);
   }
private:
   runtime_array() {}
   ~runtime_array() {}
   runtime_array( runtime_array const & );            // undefined
   runtime_array& operator=( runtime_array const & ); // undefined
};

This will ensure that user code does not by mistake create your objects in the stack nor will it mix calls to malloc/free with calls to new/delete, since you manage creation and destruction of your objects. None of this changes affects the memory layout of your objects.

David Rodríguez - dribeas
Attention: If you define copy-assignment, then runtime_array does not qualify as a POD anymore.
Luther Blissett
@Luther Blissett: right, but was it a POD in the first time? I am not talking about the compiler but the semantics. For the compiler it looks like a POD but many of the operations that can be performed on a POD cannot be performed in that object, like bitwise copying in copy assignment.
David Rodríguez - dribeas
The OP's struct looks like a POD. OTOH, referring to a non-static field of an non-POD before the constructor began execution is UB (12.7), `a=malloc(); a->size=xxx` is just that.
Luther Blissett
@Luther Blisset: Technically I agree, but in this particular case the default constructor will perform no operation at all on the memory, so the object will be exactly the same before and after calling the constructor. You could add a noop call to in-place new there: `new (a) runtime_array;`, but that is guaranteed by the standard not to do anything --an empty constructor for the class will leave the only field that the compiler could possibly touch uninitialized. I know that this is walking on the edge, but I believe that it can be assumed to be safe with the current class definition.
David Rodríguez - dribeas
David Rodríguez - dribeas
I'm totally with you in this thing. C++ is sometimes overly strict in incomprehensible ways. Anyway, if I'm getting this right then C++0x fixes this and allows PODs with *trivial* ctors/dtor/assigment which would make your code defined.
Luther Blissett
A: 

If it's complaining about the copy constructor and assignment operator functions, couldn't you supply your own. If you don't want them, declare them private.

This may produce a lot of errors elsewhere in the code if you are assigning or copying without realising it, in which case it wouldn't have worked anyway because there are no automatically generated ones.

Brian Hooper
+1  A: 

The main idea for this C (anti)pattern is to get for _TREEDATSTR elements the needed extra memory; in other words allocation will be done with malloc(sizeof(_TREEDATSTR) + len).

Pragma pack is used to ask the compiler to leave no empty spaces between the fields (normally compilers do sometimes leave some unused bytes between fields of structres to guarantee alignment because in many modern processors this is a huge speed improvement).

Note however that there are architectures where unaligned access is not just slow... but totally forbidden (segfault) so those compilers are free to ignore the pragma pack; code that uses pragma pack is inherently unportable.

I think I would have put the dword first in the structure, and this probably wouldn't have required a pragma pack; also a way to silence the warning is to allocate a one element array and doing the allocation using (len-1) extra bytes.

In C++ all this stuff is quite dangerous, because you're basically fooling the compiler into thinking that the size of the object is smaller than it really is, and given that C++ is a copy-logic language this means asking for troubles (for example for copy construction and assignment functions that will act only on the first part of the object). For everyday use it's surely MUCH better to use for example an std::vector instead, but this of course will come at an higher price (double indirection, more memory for every _TREEDATSTR instance).

I normally don't like thinking all other programmers are idiots, so if this kind of bad trickery has been used then probably there is a well paying reason for it... For a definitive judgment however a much deeper inspection would be needed.

To summarize:

  1. Using a zero element array at the end of an array is a trick used to create variable-sized objects. The allocation is done by requesting sizeof(structure) + n*sizeof(array_element) bytes.
  2. Pragma pack is used to tell the compiler to avoid adding extra padding bytes between structure fields. This is needed when a precise control on the memory layout is needed (for example because those object are being accessed by hand-written assembly)
  3. Don't do that in C++ unless you really need it and you know what you're doing

There is no way to "correctly" silence the warning because the code wants to play dirty (and C++ compilers don't like to be fooled about object size). If you use this object inside other objects, or as a base for other objects, or pass it aroud by value then whatever bad happens you asked for it.

6502