Am 13.08.2016 um 11:09 schrieb Jeff King:
On Sat, Aug 13, 2016 at 11:01:21AM +0200, René Scharfe wrote:

This section is about "The FLEXPTR_* variants", so use FLEXPTR_ALLOC_STR
in the example.

Oops, yeah. Your patch is clearly an improvement.

Since this is obviously an easy mistake to make (using one form rather
than the other), I wondered if the compiler would catch it.

I think it would catch an accidental use of FLEXPTR instead of FLEX,
because it involves an attempted assignment of an array.

Gcc 5.4 reports "invalid use of flexible array member".

But I don't
think we would catch the reverse; we'd just write the data directly on
top of the pointer. That would probably crash immediately at runtime, so
if you exercise the code at all in tests, it is OK. But something to be
aware of.

No hint at compile time, segfaults at runtime.

I suppose it could assert(sizeof((x)->flexname) == FLEX_ALLOC) or
something, but I'm not sure if it is worth worrying about.

You can't use sizeof with an actual flexible array. It only works if FLEX_ARRAY is defined as 1 (for platforms without native support), and perhaps also if it's 0.

offsetof(struct x, arr) == sizeof(struct x) won't work either because of padding.

I have no idea what you can do with a flexible array that would throw a compile error when done with a pointer.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to