A zero sized array declaration was a constraint violation (this requiring a diagnostic) in ISO C 90 in all contexts: even as a function parameter, where the identifier being declared is actually a pointer and not an array at all!
C99 added the "flexible array member" feature: the last element of a struct can be an array of size zero: "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." [C99, 6.7.2.1 ¶16]
In C90 code, the "struct hack" is implemented using an array of size [1] at the end of a struct. Some compilers allowed zero (like GNU C, I think) before C99.
In any case, supporting a [0]-sized array member which is not the last member of a struct, without issuing a diagnostic, is non-conforming. The example given in the article with consecutive [0] arrays requires a diagnostic.
By the way, the (apparently only?) advantage of the flexible array member is that we can use sizeof (type) to obtain the size of the structure just excluding the first element of the array. Whereas with the C90 style struct hack, we must use offsetof(type, last_member) so that we exclude [1] from the calculation:
struct foo {
/* ... */
int array[ZERO_OR_ONE];
};
/* Correct in C99, if ZERO_OR_ONE is 0
Incorrect in C90, (ZERO_OR_ONE can't be zero). */
size_t foo_plus_3_elems = sizeof (struct foo) + 3 * sizeof(int);
/* Correct in C99 whether or not ZERO_OR_ONE is 0 or 1.
Correct in C90 with ZERO_OR_ONE being 1. */
size_t foo_plus_3_elems = offsetof (struct foo, array) + 3 * sizeof(int);
Here, "incorrect" means we calculate slightly more storage than needed, usually without any downside.
"Correct in C90" means de facto correct, not that it was well-defined behavior. "Everyone" was doing it.
I think you made a small mistake: an "incomplete array type", as allowed by the clause you cited, is one with empty brackets (int foo[]). Per 6.7.5.2.4:
> If the size is not present, the array type is an incomplete type.
This is different from specifying the size as 0, which is still not allowed, per 6.7.5.2.1:
> In addition to optional type qualifiers and the keyword static, the [ and ] may delimit an expression or *. If they delimit an expression (which specifies the size of an array), the expression shall have an integer type. If the expression is a constant expression, it shall have a value greater than zero.
Oh, and for the record, while you may be alluding to this in your last paragraph: another advantage of flexible array members is that indexing them is actually well-defined per the spec (if enough space has been allocated, of course), while AFAIK the spec has never added a special case for length-1 arrays, so accessing the "extra elements" is technically undefined behavior. However, common compilers like GCC do treat length 1 specially, as an exception to optimizations that generally assume you won't index out of bounds, so 'technically' really is 'technically' - it's not something that some random future version of GCC is likely to break your code if you use.
Even though I got the quote right out of C99, I still mixed it up.
The reason for this is that ... I don't use flexible array member myself or the [0] GCC extension, either.
Flexible array member doesn't seem to bring anything to the table other than formal definedness of behavior. I can't imagine any implementation which supports flexible-array member in its C99+ modes, which makes [1] fail in the same modes or in the C99 mode. In any old compiler that doesn't have C99 support, that formally undefined struct hack is all you have.
I don't mind using offsetof(type, member) to obtain the size of the header before the array, rather than sizeof(type).
The classic hack is portable to C90 and C++98, making it good for "Clean C".
That said, flexible array member is elegant in the sense that it just uses an incomplete array type similarly to a file scope array declaration. Using [1] is a bit like while (1) instead of for (;;). I don't like the [1] in the struct hack, but I don't use C for its beauty.
The use of an array of size [1] at the end of a structure is far broader than users of GCC. It is not a GCC extension; it's a trick which based on undefined behavior: accessing [2], [3], [4] ... in that array based on knowing that the space was malloced, which depends on the pointer arithmetic working, while the optimizer looks the other way.
"Despite its popularity, the technique is also somewhat notorious: Dennis Ritchie has called it ``unwarranted chumminess with the C implementation,'' and an official interpretation has deemed that it is not strictly conforming with the C Standard, although it does seem to work under all known implementations. (Compilers which check array bounds carefully might issue warnings.)"
That seemed pretty straightforward to me. A zero size array is better thought of as a pointer to that part of the struct, and if you put two back to back you get two pointers to the same spot. I'm not sure what that guy was expecting to happen.
The usual reason to use them is when you have a protocol header with a variable length data portion. Putting the zero length array in the struct allows you easy access to the data while not changing the sizeof() the header so you can avoid a bit of pesky pointer math and make the code easier to read.
Thinking about this some more, you could also use this as a ghetto form of union, but I'm not sure why you would want to.
Funny, I used a union once to port code when I found-out zero sized arrays were a gcc thing:
/*
* SC C Compiler 8.8.4f1 (part of MPW 3.3) does not support zero sized
* arrays. I use this 'clever' trick involving the preprocessor that
* guarantees everything is aligned appropriately. It is possible with
* this that some space will be wasted between the header and the
* payload if the a single element of the payload is larger than the
* header, but that is not the case here.
*/
#if 0
struct state {
mbhdr_t st_mb; /* Screen 1, Line 1 */
short st_serln; /* Screen 1, Line 2 */
short st_astln;
unsigned char st_count;
unsigned char st_unit;
char st_qs[2];
char st_units; /* Screen 1, Line 3 */
avunit_t st_avms[0];
};
#else
struct state {
union {
struct {
mbhdr_t suh_mb; /* Screen 1, Line 1 */
short suh_serln; /* Screen 1, Line 2 */
short suh_astln;
unsigned char suh_count;
unsigned char suh_unit;
char suh_qs[2];
char suh_units; /* Screen 1, Line 3 */
} su_header;
avunit_t su_align[1];
} st_union[1];
};
#define st_mb st_union[0].su_header.suh_mb
#define st_serln st_union[0].su_header.suh_serln
#define st_astln st_union[0].su_header.suh_astln
#define st_count st_union[0].su_header.suh_count
#define st_unit st_union[0].su_header.suh_unit
#define st_qs st_union[0].su_header.suh_qs
#define st_units st_union[0].su_header.suh_units
#define st_avms st_union[1].su_align
#endif
> A zero size array is better thought of as a pointer to that part of the struct, ...
An array of any size is best thought of as an array. Arrays are not pointers. (See section 6 of the comp.lang.c FAQ, http://www.c-faq.com/.)
A zero size array is best thought of as illegal (if you want portability) or as a compiler-specific extension (if you don't mind depending on a particular compiler, perhaps gcc).
Technically correct, but using the zero length array trick creates clearer, more self documenting code. It's a tradeoff between readability and portability.
> C makes it very easy to get things subtly wrong. Yet another item to add to your code review checklist. Better yet, don't use zero size arrays unless you really have to.
You don't have to. C has flexible arrays in structs for this, and they actually work.
And this is why in 2016 I'm still stuck with ANSI C. First person to tell me ANSI C is not C89 anymore wins a prize!
I love C but I can't think of any other language that failed to gain traction as it got updates. Maybe similar to failure of Python 3 I guess but even Python 3 is getting reasonable uptake.
The term "ANSI C" is still very commonly used to refer to the language described by the 1989 ANSI C standard. This usage is strictly incorrect, but too firmly entrenched to ignore.
The 1990 ISO C standard describes the same language, and was officially adopted by ANSI, making the 1989 standard obsolete. The 1999 and 2011 ISO standards, both also officially adopted by ANSI, each officially made all earlier standards obsolete. If you want to refer to the language defined by the 1989 ANSI C standard (and described in K&R2), call it "C89" or "C90".
C11 might get more traction than C99 did, since gcc defaults to C11 plus GNU extensions starting with release 6. (But Microsoft's C compiler is still behind the times.)
All the compilers I ever used in my professional career could do C99 but most companies limit themselves to ANSI C (good luck convincing anyone that the term is incorrect!) for "compatibility" reasons and it's got nothing to do with Microsoft (who uses their compilers for C anyway?).
Your prize for pointing out that the usage of ANSI C is incorrect is: disappointment in humanity.
I used to use VC++ to build C code sometimes. People write software in C, and if you use VC++ you might want to compile it. C and C++ are not the same, and the fixing-up process can be time-consuming and error-prone, even assuming the code didn't go full C99 with anonymous aggregates and designated initializers.
Fortunately, these days VS2013+ do an OK job of C99.
My experience is that C99 has been universal outside the Microsoft world for years now - even for embedded programming. I can't remember the last time there was any trouble using it.
Far as I get Microsoft is a C++ shop which is why they didn't care about C after 89. For embedded stuff, my memory is hazy but I think much of what became C99 was available a number of years before the standard was released.
Because it's a widely-used hack that predates optimizers' obsessive exploitation of undefined behavior, it's become part of the language's customary semantics and is supported everywhere I know of.
C99 adds a feature called flexible array members. If the final member of a struct is an array with no length (blank rather than zero), you're allowed to use the array to access memory after the struct with the appropriate subscripts.
It's not only an optimizer that could throw you off if you really are relying on overflowing an array's bounds. While C doesn't require bounds checks, it also doesn't prohibit them, so a safety-oriented compiler could insert bounds checks (except in the special case in structs you mention, which by the standard has to be allowed). That exists in the real world too; the Intel C compiler can insert bound checks, though they aren't enabled by default.
The struct would be stored in a larger area of memory that has previously been malloc'd (to allow room for the data that you want to put after the header). So long as accesses to the data are before the end of the malloc, it won't be out of bounds and so won't be undefined behaviour.
Prior to its deletion for reasons unknown, there was a post that (reading between the lines) was calling you out on the term "access", which doesn't appear to encompass writing: http://port70.net/~nsz/c/c11/n1570.html#3.1
I'd class that as a valid quibble, if my interpretation is correct, but a quibble nonetheless. The general intent is clear enough from the standard, I think: http://port70.net/~nsz/c/c11/n1570.html#6.7.2.1p18
Your second link seems to agree with my original post, i.e. it is not UB. Read on to point 20: http://port70.net/~nsz/c/c11/n1570.html#6.7.2.1p20 and it talks about my example of putting the struct in a malloc'd area of memory with space after the struct.
What's the equivalent pattern in C++ to do this then? Specifically a contiguously allocated but variable length struct. I was thinking you can use template:
But that is not quite the same thing since ion_system_heap<10> and ion_system_heap<20> won't be the same type and makes it super hard to use. And a whole bunch of other problems like not knowing how many pages you want to allocate at compile time.
Yes you can just use a vector for "pools" but that allocates it on the heap instead of in the struct.
It solved it by wrapping with a superclass that you downcast from. You won't be able to work with them by value due to object slicing but you can still have a vector of pointers:
vector<Panda_without_bamboo*> pandas;
I am not sure how to do the downcasting though. Assuming the classes look like this:
public Panda_without_bamboo
{
int bambooCount;
}
template<std::size_t N>
class Panda_with_bamboo : public Panda_without_bamboo
{
int a;
int b;
Bamboo bamboo[N];
}
So it does seem like using flexible array members (first answer in that stackoverflow and the topic discussed in this submission) is a cleaner solution if you need contiguous allocation: http://www.codeatcpp.com/2007/10/dynamic-array-template.html
Of course you can create a vector of pointers and do whatever you want.
If you need contiguous memory though this is likely a terrible way to go about it since you are not only having to dereference pointers that could go anywhere, but each one will mean a separate heap allocation which will be slow for small objects and not scale with concurrency.
Note to future me: I checked the C++98 standard. a[i] is defined as *(a+i), the size of the array is not mentioned. So if a points somewhere where a+i is a legal access, this should be fine.
Edit: But casting the allocated memory around to a struct type might violate aliasing rules...
are valid and well defined. Part of what makes memory access validation such a pain in the ass in C++ is that no attempts are really made at specifying rules for how you can come up with memory locations; just rules on which locations you can read and write from. You can do things like "((int)rand()) = 2", and nothing in the standard says this is an invalid thing to do, so long as you are lucky enough for rand() to point somewhere allocated.
Except it requires sizeof a pointer more memory and an extra assignment after the malloc, which is why people use the zero-sized array instead (note this comment was to explain for the grandparent why you would normally prefer a zero-sized array instead).
I do that all the time, packets come in, packets go out. They have headers and 'data'. A lot of code that deals with the header information does not need to know anything about the data part.
Yes; the latter one is the "flexible array member" which is supported in ISO C99 and later. The former is a constraint violation requiring a diagnostic.
The proprietary kernel code is compiled into .o files and linked into a .a archive library.
To complete the build, a driver table module must be added and some drivers. The module which defines driver_table can be open-source. It defines the size of driver_table by how many entries there actually are; users can configure as many or few drivers and re-build the kernel, without having to recompile the proprietary part in the .a archive.
Unixes were shipped like this once upon a time. The "device major number" is just the position in the device table.
C99 added the "flexible array member" feature: the last element of a struct can be an array of size zero: "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." [C99, 6.7.2.1 ¶16]
In C90 code, the "struct hack" is implemented using an array of size [1] at the end of a struct. Some compilers allowed zero (like GNU C, I think) before C99.
In any case, supporting a [0]-sized array member which is not the last member of a struct, without issuing a diagnostic, is non-conforming. The example given in the article with consecutive [0] arrays requires a diagnostic.
By the way, the (apparently only?) advantage of the flexible array member is that we can use sizeof (type) to obtain the size of the structure just excluding the first element of the array. Whereas with the C90 style struct hack, we must use offsetof(type, last_member) so that we exclude [1] from the calculation:
Here, "incorrect" means we calculate slightly more storage than needed, usually without any downside."Correct in C90" means de facto correct, not that it was well-defined behavior. "Everyone" was doing it.