为什么我无法检索灵活的阵列成员大小？

Question

OK so I was reading the standard paper (ISO C11) in the part where it explains flexible array members (at 6.7.2.1 p18). It says this:

As a special case, the last element of a structure with more than one named member may have an incomplete array type; this is called a flexible array member. In most situations, the flexible array member is ignored. In particular, the size of the structure is as if the flexible array member were omitted except that it may have more trailing padding than the omission would imply. However, when a . (or -> ) operator has a left operand that is (a pointer to) a structure with a flexible array member and the right operand names that member, it behaves as if that member were replaced with the longest array (with the same element type) that would not make the structure larger than the object being accessed ; the offset of the array shall remain that of the flexible array member, even if this would differ from that of the replacement array. If this array would have no elements, it behaves as if it had one element but the behavior is undefined if any attempt is made to access that element or to generate a pointer one past it.

And here are some of the examples given below (p20):

EXAMPLE 2 After the declaration:

 struct s { int n; double d[]; }; 

the structure struct s has a flexible array member d. A typical way to use this is:

 int m = /* some value */; 
 struct s *p = malloc(sizeof (struct s) + sizeof (double [m])); 

and assuming that the call to malloc succeeds, the object pointed to by p behaves, for most purposes, as if p had been declared as:

 struct { int n; double d[m]; } *p; 

(there are circumstances in which this equivalence is broken; in particular, the offsets of member d might not be the same).

Added spoilers as examples inside the standard are not documentation.

And now my example (extending the one from the standard):

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
    struct s { int n; double d[]; };

    int m = 7;

    struct s *p = malloc(sizeof (struct s) + sizeof (double [m])); //create our object

    printf("%zu", sizeof(p->d)); //retrieve the size of the flexible array member

    free(p); //free out object
}

Online example .

Now the compiler is complaining that p->d has incomplete type double[] which is clearly not the case according the standard paper. Is this a bug in the GCC compiler?

Answer 1

As a special case, the last element of a structure with more than one named member may have an incomplete array type ; ... C11dr 6.7.2.1 18

In the following d is an incomplete type.

struct s { int n; double d[]; };

The sizeof operator shall not be applied to an expression that has function type or an incomplete type ... C11dr §6.5.3.4 1

// This does not change the type of field `m`.
// It (that is `d`) behaves like a `double d[m]`, but it is still an incomplete type.
struct s *p = foo();

// UB
printf("%zu", sizeof(p->d));

Answer 2

This looks like a defect in the Standard. We can see from the paper where flexible array members were standardized, N791 "Solving the struct hack problem" , that the struct definition replacement is intended to apply only in evaluated context (to borrow the C++ terminology); my emphasis:

When an lvalue whose type is a structure with a flexible array member is used to access an object , it behaves as if that member were replaced by the longest array that would not make the structure larger than the object being accessed.

Compare the eventual standard language:

[W]hen a . (or -> ) operator has a left operand that is (a pointer to) a structure with a flexible array member and the right operand names that member, it behaves as if that member were replaced with the longest array (with the same element type) that would not make the structure larger than the object being accessed [...]

Some form of language like " When a . (or -> ) operator whose left operand is (a pointer to) a structure with a flexible array member and whose right operand names that member is evaluated [...] " would seem to work to fix it.

(Note that sizeof does not evaluate its argument, except for variable length arrays, which are another kettle of fish.)

There is no corresponding defect report visible via the JTC1/SC22/WG14 website . You might consider submitting a defect report via your ISO national member body, or asking your vendor to do so.

Answer 3

Standard says:

C11-§6.5.3.4/2

The sizeof operator yields the size (in bytes) of its operand, which may be an expression or the parenthesized name of a type. The size is determined from the type of the operand .

and it also says
C11-§6.5.3.4/1

The sizeof operator shall not be applied to an expression that has function type or an incomplete type , [...]

p->d is of incomplete type and it can't be an operand of sizeof operator. The statement

it behaves as if that member were replaced with the longest array (with the same element type) that would not make the structure larger than the object being accessed

doesn't hold for sizeof operator as it determine size of the object by the type of object which must be a complete type.

Answer 4

First, what is happening is correct in terms of the standard, arrays that are declared [] are incomplete and you can't use the sizeof operator.

But there is also a simple reason for it in your case. You never told your compiler that in that particular case the d member should be viewed as of a particular size. You only told malloc the total memory size to be reserved and placed p to point to that. The compiler has obtained no type information that could help him deduce the size of the array.

This is different from allocating a variable length array (VLA) or a pointer to VLA:

 double (*q)[m] = malloc(sizeof(double[m]));

Here the compiler can know what type of array q is pointing to. But not because you told malloc the total size (that information is not returned from the malloc call) but because m is part of the type specification of q .

Answer 5

The C Standard is a bit loosey-goosey when it comes to the definition of certain terms in certain contexts. Given something like:

struct foo {uint32_t x; uint16_t y[]; };
char *p = 1024+(char*)malloc(1024);  // Point to end of region
struct foo *q1 = (struct foo *)(p -= 512); // Allocate some space from it
... some code which uses *q1
struct foo *q2 = (struct foo *)(p -= 512); // Allocate more space from it

there's no really clear indication of what storage is occupied by objects *q1 or *q2, nor by q1->y or q2->y. If *q1 will never be accessed afterward, then q2->y may be treated as a uint16_t[509], but writing to *q1 will trash the contents of q2->y[254] and above, and writing q2->y[254] and above will trash *q1. Since a compiler will generally have no way of knowing what will happen to *q1 in the future, it will have no way of sensibly reporting a size for q2->y.