I recently read that using flexible array members in C was poor software engineering practice. However, that statement was not backed by any argument. Is this an accepted fact?
(Flexible array members are a C feature introduced in C99 whereby one can declare the last element to be an array of unspecified size. For example: )
struct header {
size_t len;
unsigned char data[];
};
It is an accepted "fact" that using goto is poor software engineering practice. That doesn't make it true. There are times when goto is useful, particularly when handling cleanup and when porting from assembler.
Flexible array members strike me as having one main use, off the top of my head, which is mapping legacy data formats like window template formats on RiscOS. They would have been supremely useful for this about 15 years ago, and I'm sure there are still people out there dealing with such things who would find them useful.
If using flexible array members is bad practice, then I suggest that we all go tell the authors of the C99 spec this. I suspect they might have a different answer.
while, then. –
Elysha goto is not for loops. –
Shooin sizeof(struct header) is added to sizeof(unsigned char) * n before being malloc()ed, where n is the desired length of data`. Exercise caution, however; API functions have no idea how much memory you've allocated, and will readily segfault if you tell them your array is bigger than it actually is –
Puttier while and for had a lot of semantics under those very terse statements. I would like to see a single yet simple loop statement that works with goto (in place of "break" and "continue") as a replacement for while and for. Complex loops will be documented with well-named labels inside a loop block; for everything simpler, you just loop if (predicate_expression) block, loop quantifier block, or loop block. And let's not forget the obvious: goto jump tables (aka switches with user-defined semantics)! Very useful for directed graph logic programming! –
Polluted No, using flexible array members in C is not bad practice.
This language feature was first standardized in ISO C99, 6.7.2.1 (16). In the following revision, ISO C11, it is specified in Section 6.7.2.1 (18).
You can use them like this:
struct Header {
size_t d;
long v[];
};
typedef struct Header Header;
size_t n = 123; // can dynamically change during program execution
// ...
Header *h = malloc(sizeof(Header) + sizeof(long[n]));
h->n = n;
Alternatively, you can allocate like this:
Header *h = malloc(sizeof *h + n * sizeof h->v[0]);
Note that sizeof(Header) includes eventual padding bytes, thus, the following allocation is incorrect and may yield a buffer overflow:
Header *h = malloc(sizeof(size_t) + sizeof(long[n])); // invalid!
A struct with a flexible array members reduces the number of allocations for it by 1/2, i.e. instead of 2 allocations for one struct object you need just 1. Meaning less effort and less memory occupied by memory allocator bookkeeping overhead. Furthermore, you save the storage for one additional pointer. Thus, if you have to allocate a large number of such struct instances you measurably improve the runtime and memory usage of your program (by a constant factor).
In contrast to that, using non-standardized constructs for flexible array members that yield undefined behavior (e.g. as in long v[0]; or long v[1];) obviously is bad practice. Thus, as any undefined-behaviour this should be avoided.
Since ISO C99 was released in 1999, more than 20 years ago, striving for ISO C89 compatibility is a weak argument.
PLEASE READ CAREFULLY THE COMMENTS BELOW THIS ANSWER
As C Standardization move forward there is no reason to use [1] anymore.
The reason I would give for not doing it is that it's not worth it to tie your code to C99 just to use this feature.
The point is that you can always use the following idiom:
struct header {
size_t len;
unsigned char data[1];
};
That is fully portable. Then you can take the 1 into account when allocating the memory for n elements in the array data :
ptr = malloc(sizeof(struct header) + (n-1));
If you already have C99 as requirement to build your code for any other reason or you are target a specific compiler, I see no harm.
strcpy(data, sometext) you will get buffer underrun errors at runtime. –
Poddy [1] trick to work just as well as [] (aside from possibly wasting a few extra bytes of storage). –
Diphtheria n-1 does not accurately accounts for the extra allocation, because of alignment: on most 32-bit machines, sizeof(struct header) will be 8 (to remain multiple of 4, since it has a 32-bit field which prefers/requires such alignment). The "better" version is: malloc(offsetof(struct header, data) + n) –
Thresher data[1]. Of course malloc() can (and usually will) allocate more memory to comply with the alignment rules or do whatever it needs to do to manage the memory block. –
Candiecandied unsigned char data[1] isn't portable because ((header*)ptr)->data + 2 -- even if enough space was allocated -- creates a pointer that points outside the length-1 array object (and not the sentinel one past the end). But per C99 6.5.6p8, "If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined" (emphasis added). Flexible arrays (6.7.2.2p16) act like an array filling the allocated space to not hit UB here. –
Daubery [1] must work as well as [] but the first example in this post comes close: GCC (and not even particularly recent versions of it) assume that accesses to an array member remain within the array. It is by courtesy that GCC doesn't assume q->tab[2] is an unreachable expression in the second example. blog.frama-c.com/index.php?post/2013/07/31/… –
Descend q->tab decays to is also a pointer to a part of the representation of the entire object. –
Diphtheria [1] has been shown to cause GCC to generate incorrect code: lkml.org/lkml/2015/2/18/407 –
Amazing struct S contains int foo[1], a compiler should be allowed to replace foo[i] with foo[0]; if zero-element arrays were allowed, accessing array elements beyond [size-1u] was UB, such substitution would be legal but... –
Sohn S has foo[0] as its last element: struct S foo[3]+[5]; would declare an array of three structures, each of which had space for five elements in its foo array.] IMHO, that would be much nicer than anything presently allowed with flexible array members. –
Sohn foo[i] with foo[0], or the idea that zero-sized objects should be allowed provided programs don't perform arithmetic on pointers to such objects [just as they're forbidden from performing arithmetic on void*]? Having a compiler replace foo[i] with foo[0] would be downright benign compared with hyper-modern optimizations. –
Sohn dat[1] but then dereferencing data beyond that, disapproving of allowing such accesses with a zero-element array, or both? I don't like the former, but historically it was rendered necessary by the prohibition against zero-element arrays; I'd say that having compilers not bother yielding an error for zero-element arrays but requiring that arrays be accessed in the range 0 to size-(size_t)1 would have been simpler and cleaner from both a coding and compiler perspective. –
Sohn uint32_t first_two_fields; int field1 = first_two_fields.0:23; int field2 = first_two_fields.23:9; would mean that field1 would occupy the lower 23 bits of first_two_fields and field2 would occupy the upper 9 bits). That would have allowed for useful optimizations... –
Sohn sizeof to it –
Kowalczyk struct x {uint32_t x; uint8_t y; uint16_t z[];} I would have specified that the offset of z should be the same as for any fixed size (and all fixed sizes should imply the same offset), and sizeof (struct x) should yield the offset of z. –
Sohn sizeof(struct x) does yield the offset. There may be padding before z according to the standard, but IMO that is not an issue, as (a) there may be padding almost anywhere and in practice compilers only use padding where required for alignment, and (b) it's easy enough to write code that checks for padding, and/or does not rely on padding's presence –
Kowalczyk sizeof than the offsetof in a case I tried... I agree that this is lame , however maybe the gcc developers had backwards compaitibility of some sort in mind. gcc does seem to implement array of f.a.m. structs as an extension –
Kowalczyk [1] will result in bound violation reports when using gcc -mmpx -fcheck-pointer-bounds. –
Lura foo[1] instead of foo[] isn't just wrong in that it isn't portable, it is dangerously wrong, as it causes undefined behavior -- making compilers silently generate incorrect/unintended bytecode. –
Zenobia You meant...
struct header
{
size_t len;
unsigned char data[];
};
In C, that's a common idiom. I think many compilers also accept:
unsigned char data[0];
Yes, it's dangerous, but then again, it's really no more dangerous than normal C arrays - i.e., VERY dangerous ;-) . Use it with care and only in circumstances where you truly need an array of unknown size. Make sure you malloc and free the memory correctly, using something like:-
foo = malloc(sizeof(header) + N * sizeof(data[0]));
foo->len = N;
An alternative is to make data just be a pointer to the elements. You can then realloc() data to the correct size as required.
struct header
{
size_t len;
unsigned char *data;
};
Of course, if you were asking about C++, either of these would be bad practice. Then you'd typically use STL vectors instead.
I've seen something like this: from C interface and implementation.
struct header {
size_t len;
unsigned char *data;
};
struct header *p;
p = malloc(sizeof(*p) + len + 1 );
p->data = (unsigned char*) (p + 1 ); // memory after p is mine!
Note: data need not be last member.
data need not be the last member, but it also incurs an extra dereference every time data is used. Flexible arrays replace that dereference with a constant offset from the main struct pointer, which is free on some particularly common machines and cheap elsewhere. –
Diphtheria unsigned char *, p->data = (unsigned char*) (p + 1 ) is OK. Yet with double complex *, p->data = (double complex *) (p + 1 ) may cause alignment problems. –
Baltoslavic As a side note, for C89 compatibility, such structure should be allocated like :
struct header *my_header
= malloc(offsetof(struct header, data) + n * sizeof my_header->data);
Or with macros :
#define FLEXIBLE_SIZE SIZE_MAX /* or whatever maximum length for an array */
#define SIZEOF_FLEXIBLE(type, member, length) \
( offsetof(type, member) + (length) * sizeof ((type *)0)->member[0] )
struct header {
size_t len;
unsigned char data[FLEXIBLE_SIZE];
};
...
size_t n = 123;
struct header *my_header = malloc(SIZEOF_FLEXIBLE(struct header, data, n));
Setting FLEXIBLE_SIZE to SIZE_MAX almost ensures this will fail :
struct header *my_header = malloc(sizeof *my_header);
[1] for C89 compatibility, if it's even needed... –
Diphtheria There are some downsides related to how structs are sometimes used, and it can be dangerous if you don't think through the implications.
For your example, if you start a function:
void test(void) {
struct header;
char *p = &header.data[0];
...
}
Then the results are undefined (since no storage was ever allocated for data). This is something that you will normally be aware of, but there are cases where C programmers are likely used to being able to use value semantics for structs, which breaks down in various other ways.
For instance, if I define:
struct header2 {
int len;
char data[MAXLEN]; /* MAXLEN some appropriately large number */
}
Then I can copy two instances simply by assignment, i.e.:
struct header2 inst1 = inst2;
Or if they are defined as pointers:
struct header2 *inst1 = *inst2;
This however won't work for flexible array members, since their content is not copied over. What you want is to dynamically malloc the size of the struct and copy over the array with memcpy or equivalent.
struct header3 {
int len;
char data[]; /* flexible array member */
}
Likewise, writing a function that accepts a struct header3 will not work, since arguments in function calls are, again, copied by value, and thus what you will get is likely only the first element of your flexible array member.
void not_good ( struct header3 ) ;
This does not make it a bad idea to use, but you do have to keep in mind to always dynamically allocate these structures and only pass them around as pointers.
void good ( struct header3 * ) ;
© 2022 - 2024 — McMap. All rights reserved.