In C (C99 and later), a flexible array member can be defined with [], and must be the last member of a structure. C++ doesn't support flexible array members, but g++ permits them as a language extension.

Older versions of g++ do not require a flexible array member to be the last member of a class or struct. This is a bug, which has been corrected in newer versions of g++.

Here's a small test program, based on yours that illustrates the problem:

#include <iostream>
#include <cstddef>

static int mem[100];

struct test{
        int a;
        int b[];
        int c;
};

int main(){     
    test *ptr = (test*)&mem;
    ptr->a = 10;
    ptr->b[0] = 20;
    ptr->b[1] = 30;
    ptr->c = 40;

    std::cout << "ptr->a    = " << ptr->a << "\n";
    std::cout << "ptr->b[0] = " << ptr->b[0] << "\n";
    std::cout << "ptr->b[1] = " << ptr->b[1] << "\n";
    std::cout << "ptr->c    = " << ptr->c << "\n";
}

And here's the output when I compile it with g++ 4.1.2:

ptr->a    = 10
ptr->b[0] = 40
ptr->b[1] = 30
ptr->c    = 40

As you can see, the member c is allocated at the same offset as b[0].

(Strictly speaking, using an int[] array to hold a test object isn't 100% safe due to possible alignment problems, but that's unlikely to be an issue in practice.)

It's very likely that your code has undiscovered bugs because of this.

Your problem is not that the newer g++ rejects your code; it's that the older one doesn't.

Reordering the member declarations so the flexible array member appears last is the simplest fix -- though you (or someone else) will need to carefully examine how the type is used. A far better solution is probably to replace the flexible array member with some C++ container class, perhaps a std::vector.

(I have no chance of changing the code, it's not under my control)

Somebody is able to change the code, and presumably you're able to submit a bug report.

No, flexible arrays must always be allocated manually. But you may use calloc to initialize the flexible part and a compound literal to initialize the fixed part. I'd wrap that in an allocation inline function like this:

Copytypedef struct person {
  unsigned age;
  char sex;
  size_t size;
  char name[];
} person;

inline
person* alloc_person(int a, char s, size_t n) {
  person * ret = calloc(sizeof(person) + n, 1);
  if (ret) memcpy(ret,
                  &(person const){ .age = a, .sex = s, .size = n},
                  sizeof(person));
  return ret;
}

Observe that this leaves the check if the allocation succeeded to the caller.

If you don't need a size field as I included it here, a macro would even suffice. Only that it would be not possible to check the return of calloc before doing the memcpy. Under all systems that I programmed so far this will abort relatively nicely. Generally I think that return of malloc is of minor importance, but opinions vary largely on that subject.

This could perhaps (in that special case) give more opportunities to the optimizer to integrate the code in the surroundings:

Copy#define ALLOC_PERSON(A,  S,  N)                                 \
((person*)memcpy(calloc(sizeof(person) + (N), 1),               \
                 &(person const){ .age = (A), .sex = (S) },     \
                 sizeof(person)))

Edit: The case that this could be better than the function is when A and S are compile time constants. In that case the compound literal, since it is const qualified, could be allocated statically and its initialization could be done at compile time. In addition, if several allocations with the same values would appear in the code the compiler would be allowed to realize only one single copy of that compound literal.