Given the following:

struct foo {
/* other members */
char prefix[PREFIX_SIZE];
char name[];
};

Is there any circumstance in which the compiler is permitted to insert
padding between the 'prefix' and 'name' members?

I'm 99% sure than the answer is no, but I've been unable to track down
the actual rules anywhere.

--
========================================================================
Ian Pilcher arequipeno@gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================

On 8/2/21 1:48 PM, Ian Pilcher wrote:
> Given the following:
>
> struct foo {
> /* other members */

Note: this is a VLA unless PREFIX_SIZE is a macro that expands to an
integer constant expression.

> char prefix[PREFIX_SIZE];

This is NOT a VLA - it is a flexible array member:

> char name[];
> };
>
> Is there any circumstance in which the compiler is permitted to insert
> padding between the 'prefix' and 'name' members?
>
> I'm 99% sure than the answer is no, but I've been unable to track down
> the actual rules anywhere.

"There may be unnamed padding within a structure object, but not at its
beginning." (6.7.2.1p15).

Thus, the only restriction on such padding is that it can't be at the
beginning. I know of no other restrictions on the presence, the size, or
the location of any such padding.

There are some relevant special rules covering flexible array members,
but they don't revoke the permission give by 6.7.2.1p15 to have such
padding:

"... 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." (6.7.2.1p18)

Since the replacement array would be allowed to have padding that
separates it from the prefix array, then that is also permitted for the
flexible array member.

On 02/08/2021 18:48, Ian Pilcher wrote:
> Given the following:
>
>   struct foo {
>       /* other members */
>       char prefix[PREFIX_SIZE];
>       char name[];
>   };
>
> Is there any circumstance in which the compiler is permitted to insert
> padding between the 'prefix' and 'name' members?
>
> I'm 99% sure than the answer is no, but I've been unable to track down
> the actual rules anywhere.
>

I think only for alignment purposes. And there is no need when name has
char[] type. With int name[], then possibly.

BTW there is no VLA here unless PREFIX_SIZE is not a compile-time
expression (and I'm not sure even then).

Ian Pilcher <arequipeno@gmail.com> writes:
> Given the following:
>
> struct foo {
> /* other members */
> char prefix[PREFIX_SIZE];
> char name[];
> };
>
> Is there any circumstance in which the compiler is permitted to insert
> padding between the 'prefix' and 'name' members?
>
> I'm 99% sure than the answer is no, but I've been unable to track down
> the actual rules anywhere.

I'm 99% sure the answer is "always".

Compilers typically insert padding only when it's necessary to meet
alignment requirements, but compilers are allowed to insert arbitrary
padding between members.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 02/08/2021 19:12, Keith Thompson wrote:
> Ian Pilcher <arequipeno@gmail.com> writes:
>> Given the following:
>>
>> struct foo {
>> /* other members */
>> char prefix[PREFIX_SIZE];
>> char name[];
>> };
>>
>> Is there any circumstance in which the compiler is permitted to insert
>> padding between the 'prefix' and 'name' members?
>>
>> I'm 99% sure than the answer is no, but I've been unable to track down
>> the actual rules anywhere.
>
> I'm 99% sure the answer is "always".
>
> Compilers typically insert padding only when it's necessary to meet
> alignment requirements, but compilers are allowed to insert arbitrary
> padding between members.
>

But not for no reason, surely? And not when #pragma pack(1) is in effect.

And whatever padding might be inserted, the same rules must be in effect
across all compilers for that platform, otherwise functions in modules
and in external libraries created with mixed compilers can't call each
other.

Since I am familiar with duplicating with layout of C structs from
outside the language, to the extent of also duplicating the algorithms
for alignment and padding, this would be an impossible task if
effectively random padding could be inserted.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 8/2/21 1:48 PM, Ian Pilcher wrote:
>> Given the following:
>>
>> struct foo {
>> /* other members */
>
> Note: this is a VLA unless PREFIX_SIZE is a macro that expands to an
> integer constant expression.
>
>> char prefix[PREFIX_SIZE];

This cannot be a VLA because VLAs are not allowed as struct or union members.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Bart <bc@freeuk.com> writes:
> On 02/08/2021 18:48, Ian Pilcher wrote:
>> Given the following:
>>   struct foo {
>>       /* other members */
>>       char prefix[PREFIX_SIZE];
>>       char name[];
>>   };
>> Is there any circumstance in which the compiler is permitted to
>> insert
>> padding between the 'prefix' and 'name' members?
>> I'm 99% sure than the answer is no, but I've been unable to track
>> down
>> the actual rules anywhere.
>
> I think only for alignment purposes. And there is no need when name
> has char[] type. With int name[], then possibly.

Compilers are unlikely to insert padding other than for alignment
purposes, but the standard doesn't make that restriction. A conforming
compiler can add as much padding as it likes between members or after
the last member (if the last member isn't a flexible array member, which
it is in this case).

> BTW there is no VLA here unless PREFIX_SIZE is not a compile-time
> expression (and I'm not sure even then).

If PREFIX_SIZE is not a compile time expression, it's a constraint
violation. Struct and union member cannot be VLAs. (Also, VLA support
is optional as of C11.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 8/2/2021 10:48 AM, Ian Pilcher wrote:
> Given the following:
>
>   struct foo {
>       /* other members */
>       char prefix[PREFIX_SIZE];
>       char name[];
>   };
>
> Is there any circumstance in which the compiler is permitted to insert
> padding between the 'prefix' and 'name' members?
>
> I'm 99% sure than the answer is no, but I've been unable to track down
> the actual rules anywhere.
>

As far as the formal rules of the language are considered, the compiler
is _always_ permitted to insert padding between struct members (and
after the last member) for whatever reason it pleases. Extra padding can
always be added anywhere, except before the first member of the struct.

So, the answer is "yes".

Also, it is not clear why you mention VLA in the title of your question.
The language does not allow VLA as a struct members. The last member of
your struct is called "flexible array member". This is not VLA and has
nothing to do with VLA.

--
Best regards,
Andrey Tarasevich

On 8/2/21 12:48 PM, Ian Pilcher wrote:
> Given the following:
>
>   struct foo {
>       /* other members */
>       char prefix[PREFIX_SIZE];
>       char name[];
>   };

As has been pointed out, the 'name' member is a flexible array member,
not a variable length array. I apologize for the mistake.

Also, PREFIX_SIZE is intended to represent a macro that expands to a
positive(!) integer constant expression.

The consensus seems to be that no one can think of a good reason that a
compiler would insert padding between the 'prefix' and 'name' members,
but there's nothing in any of the language standards that would forbid
it from doing so. That would certainly explain my failure to find any
such rule.

(_Static_assert here I come!)

Thanks!

--
========================================================================
Ian Pilcher arequipeno@gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================

On 02/08/2021 19:27, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:

>> BTW there is no VLA here unless PREFIX_SIZE is not a compile-time
>> expression (and I'm not sure even then).
>
> If PREFIX_SIZE is not a compile time expression, it's a constraint
> violation. Struct and union member cannot be VLAs. (Also, VLA support
> is optional as of C11.)
>

This program works on gcc, tcc and lccwin:

#include <stdio.h>
int main(void) {
int n=100;
typedef struct{int xx[n];} S;

S a;

printf("sizeof(S) = %d\n",(int)sizeof(S));
}

The output is respectively 400, 8 and 32.

It fails with DMC, clang, msvc and bcc (but the last two don't support
VLAs anyway).

The mind boggles as to how it's implemented, for example with static,
auto and heap-allocated arrays of S, or with linked lists using S nodes,
or when S itself contains structs with such VLAs.

Ian Pilcher <arequipeno@gmail.com> writes:

> On 8/2/21 12:48 PM, Ian Pilcher wrote:
>
>> Given the following:
>>
>> struct foo {
>> /* other members */
>> char prefix[PREFIX_SIZE];
>> char name[];
>> };
>
> As has been pointed out, the 'name' member is a flexible array member,
> not a variable length array. I apologize for the mistake.
>
> Also, PREFIX_SIZE is intended to represent a macro that expands to a
> positive(!) integer constant expression.
>
> The consensus seems to be that no one can think of a good reason that a
> compiler would insert padding between the 'prefix' and 'name' members,
> but there's nothing in any of the language standards that would forbid
> it from doing so. That would certainly explain my failure to find any
> such rule.
>
> (_Static_assert here I come!)

I am curious to know why you care. Would having a guarantee that
there is no padding affect what code you would write? If it
would then there is a good chance that guarantee-depending code
has undefined behavior somewhere.

On 8/2/2021 12:43 PM, Bart wrote:
>>
>
> This program works on gcc, tcc and lccwin:
>
> #include <stdio.h>
> int main(void) {
>     int n=100;
>     typedef struct{int xx[n];} S;
>
>     S a;
>
>     printf("sizeof(S) = %d\n",(int)sizeof(S));
> }
>
> The output is respectively 400, 8 and 32.
>
> It fails with DMC, clang, msvc and bcc (but the last two don't support
> VLAs anyway).

It will fail in GCC as well if you run it in `-pedantic` mode.

> The mind boggles as to how it's implemented, for example with static,
> auto and heap-allocated arrays of S, or with linked lists using S nodes,
> or when S itself contains structs with such VLAs.

There's nothing mind-boggling about how it is implemented once you
realize that this is allowed for trailing array member only. This GCC
extension is a hybrid of "flexible array member" memory layout and VLA
semantics.

--
Best regards,
Andrey Tarasevich

Bart <bc@freeuk.com> writes:
> On 02/08/2021 19:12, Keith Thompson wrote:
>> Ian Pilcher <arequipeno@gmail.com> writes:
>>> Given the following:
>>>
>>> struct foo {
>>> /* other members */
>>> char prefix[PREFIX_SIZE];
>>> char name[];
>>> };
>>>
>>> Is there any circumstance in which the compiler is permitted to insert
>>> padding between the 'prefix' and 'name' members?
>>>
>>> I'm 99% sure than the answer is no, but I've been unable to track down
>>> the actual rules anywhere.
>> I'm 99% sure the answer is "always".
>> Compilers typically insert padding only when it's necessary to meet
>> alignment requirements, but compilers are allowed to insert arbitrary
>> padding between members.
>
> But not for no reason, surely? And not when #pragma pack(1) is in effect.

Yes, for no reason.

To be clear, I was talking about what the C standard permits.

The standard says that padding may be inserted between members. It says
nothing about what reasons a compiler must have for doing so. A
compiler that inserts unneeded padding "for no reason" would likely be a
poor compiler, but it would not violate the standard.

#pragma pack is non-standard.

> And whatever padding might be inserted, the same rules must be in
> effect across all compilers for that platform, otherwise functions in
> modules and in external libraries created with mixed compilers can't
> call each other.

Requirements on alignment and structure layout are typically imposed by
ABIs, not by the C standard. The standard has some requirements for
struct layout (you can read the relevant section yourself if you're
interested), but those requirements do not include any restrictions on
the size of padding.

> Since I am familiar with duplicating with layout of C structs from
> outside the language, to the extent of also duplicating the algorithms
> for alignment and padding, this would be an impossible task if
> effectively random padding could be inserted.

ABIs.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 8/2/2021 1:11 PM, Andrey Tarasevich wrote:
>
> There's nothing mind-boggling about how it is implemented once you
> realize that this is allowed for trailing array member only. This GCC
> extension is a hybrid of "flexible array member" memory layout and VLA
> semantics.
>

An interesting experiment that immediately comes to mind

int n=100;
typedef struct{ int xx[n]; } S;

S a;
int i = 0;

printf("%zu\n", sizeof(*(++i, &a.xx)));
printf("%d\n", i);

printf("%zu\n", sizeof(*(++i, &a)));
printf("%d\n", i);

outputs

400
1
400
1

which indicates that GCC perceives `a.xx` as an entity having variably
modified type (a VLA), but doesn't dare to go as far as treating the
struct type itself as a variably modified type.

--
Best regards,
Andrey Tarasevich

Bart <bc@freeuk.com> writes:
> On 02/08/2021 19:27, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> BTW there is no VLA here unless PREFIX_SIZE is not a compile-time
>>> expression (and I'm not sure even then).
>> If PREFIX_SIZE is not a compile time expression, it's a constraint
>> violation. Struct and union member cannot be VLAs. (Also, VLA support
>> is optional as of C11.)
>
> This program works on gcc, tcc and lccwin:
>
> #include <stdio.h>
> int main(void) {
> int n=100;
> typedef struct{int xx[n];} S;
>
> S a;
>
> printf("sizeof(S) = %d\n",(int)sizeof(S));
> }
>
> The output is respectively 400, 8 and 32.
>
> It fails with DMC, clang, msvc and bcc (but the last two don't support
> VLAs anyway).

To be a bit clearer, defining a struct member as a VLA is a constraint
violation. A conforming C compiler must diagnose it. It can then
proceed to generate code for it -- or a non-conforming compiler (such as
gcc by default) can do anything it likes.

> The mind boggles as to how it's implemented, for example with static,
> auto and heap-allocated arrays of S, or with linked lists using S
> nodes, or when S itself contains structs with such VLAs.

gcc's extension does not include support for static structs with VLA
members. The other cases don't strike me as particularly difficult,
though of course they require a bit more work than for structs whose
size is known at compile time.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Ian Pilcher <arequipeno@gmail.com> writes:
> On 8/2/21 12:48 PM, Ian Pilcher wrote:
>> Given the following:
>>   struct foo {
>>       /* other members */
>>       char prefix[PREFIX_SIZE];
>>       char name[];
>>   };
>
> As has been pointed out, the 'name' member is a flexible array member,
> not a variable length array. I apologize for the mistake.
>
> Also, PREFIX_SIZE is intended to represent a macro that expands to a
> positive(!) integer constant expression.
>
> The consensus seems to be that no one can think of a good reason that a
> compiler would insert padding between the 'prefix' and 'name' members,
> but there's nothing in any of the language standards that would forbid
> it from doing so. That would certainly explain my failure to find any
> such rule.
>
> (_Static_assert here I come!)

The ABI for whatever target platform you're interested in might have
something to say about it.

(I can imagine that some compiler might find it convenient to give the
name[] member an alignment stricter than 1 byte.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 8/2/21 2:47 PM, Tim Rentsch wrote:
> I am curious to know why you care. Would having a guarantee that
> there is no padding affect what code you would write? If it
> would then there is a good chance that guarantee-depending code
> has undefined behavior somewhere.

It's just a convenient way to refer to either the "full" name (including
the prefix) or the unique part of the name. For example, I've got a
bunch of struct foo's, each of which has a name that starts with "FOO:",
and most of the time I don't care about the prefix.

#define FOO_PREFIX "FOO:"

static const char foo_prefix[sizeof FOO_PREFIX - 1] = FOO_PREFIX;

struct foo {
/* other members */
char prefix[sizeof foo_prefix];
char name[];
}

struct foo *alloc_foo(char *name)
{
struct foo *f;

f = malloc(sizeof *f + strlen(name) + 1);

// Or do something clever with sprintf()
memcpy(&f->prefix, foo_prefix, sizeof foo_prefix);
memcpy(&f->name, name, strlen(name) + 1);

return f;
}

For a given struct foo *f, I can access the full name as f->prefix, and
I can access the unique part as f->name.

--
========================================================================
Ian Pilcher arequipeno@gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> On 8/2/2021 12:43 PM, Bart wrote:
>>>
>> This program works on gcc, tcc and lccwin:
>> #include <stdio.h>
>> int main(void) {
>>     int n=100;
>>     typedef struct{int xx[n];} S;
>>     S a;
>>     printf("sizeof(S) = %d\n",(int)sizeof(S));
>> }
>> The output is respectively 400, 8 and 32.
>> It fails with DMC, clang, msvc and bcc (but the last two don't
>> support VLAs anyway).
>
> It will fail in GCC as well if you run it in `-pedantic` mode.
>
>> The mind boggles as to how it's implemented, for example with
>> static, auto and heap-allocated arrays of S, or with linked lists
>> using S nodes, or when S itself contains structs with such VLAs.
>
> There's nothing mind-boggling about how it is implemented once you
> realize that this is allowed for trailing array member only. This GCC
> extension is a hybrid of "flexible array member" memory layout and VLA
> semantics.

No, gcc's extension appears to allow VLAs as struct members. This
compiles and runs without error and, as expected, prints different
values when it's executed again after more than a second:

#include <stdio.h>
#include <time.h>
#include <stddef.h>
int main(void) {
const int size = time(NULL) % 10 + 10;
struct s {
char s0[size];
char s1[size];
char s2[size];
};

struct s obj;

printf("sizeof obj = %zu\n", sizeof obj);
printf("%zu %zu %zu\n",
offsetof(struct s, s0),
offsetof(struct s, s1),
offsetof(struct s, s2));
}

(I didn't find this extension in gcc's documentation, but I didn't look
very hard.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Ian Pilcher <arequipeno@gmail.com> writes:
> On 8/2/21 2:47 PM, Tim Rentsch wrote:
>> I am curious to know why you care. Would having a guarantee that
>> there is no padding affect what code you would write? If it
>> would then there is a good chance that guarantee-depending code
>> has undefined behavior somewhere.
>
> It's just a convenient way to refer to either the "full" name (including
> the prefix) or the unique part of the name. For example, I've got a
> bunch of struct foo's, each of which has a name that starts with "FOO:",
> and most of the time I don't care about the prefix.
>
> #define FOO_PREFIX "FOO:"
>
> static const char foo_prefix[sizeof FOO_PREFIX - 1] = FOO_PREFIX;
>
> struct foo {
> /* other members */
> char prefix[sizeof foo_prefix];
> char name[];
> }
>
> struct foo *alloc_foo(char *name)
> {
> struct foo *f;
>
> f = malloc(sizeof *f + strlen(name) + 1);
>
> // Or do something clever with sprintf()
> memcpy(&f->prefix, foo_prefix, sizeof foo_prefix);
> memcpy(&f->name, name, strlen(name) + 1);
>
> return f;
> }
>
> For a given struct foo *f, I can access the full name as f->prefix, and
> I can access the unique part as f->name.

Suggestion: Combine `prefix` and `name` into a single array of char, and
use `name+offset` to refer to the portion of the string following the
prefix. Arrays are guaranteed to be contiguous.

If f->name contains a string whose length is at least 4, then f-name and
f->name+4 are both valid pointers to strings.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Ian Pilcher <arequipeno@gmail.com> wrote:
> On 8/2/21 2:47 PM, Tim Rentsch wrote:
> > I am curious to know why you care. Would having a guarantee that
> > there is no padding affect what code you would write? If it
> > would then there is a good chance that guarantee-depending code
> > has undefined behavior somewhere.
>
> It's just a convenient way to refer to either the "full" name (including
> the prefix) or the unique part of the name. For example, I've got a
> bunch of struct foo's, each of which has a name that starts with "FOO:",
> and most of the time I don't care about the prefix.
>
> #define FOO_PREFIX "FOO:"
>
> static const char foo_prefix[sizeof FOO_PREFIX - 1] = FOO_PREFIX;
>
> struct foo {
> /* other members */
> char prefix[sizeof foo_prefix];
> char name[];
> }
>
> struct foo *alloc_foo(char *name)
> {
> struct foo *f;
>
> f = malloc(sizeof *f + strlen(name) + 1);
>
> // Or do something clever with sprintf()
> memcpy(&f->prefix, foo_prefix, sizeof foo_prefix);
> memcpy(&f->name, name, strlen(name) + 1);
>
> return f;
> }
>
> For a given struct foo *f, I can access the full name as f->prefix,

No, you can not. Going above prefix length is undefined behaviour.
I know no "production" compiler that would detect it, but there
are various debugging aids and some should catch it.

> and
> I can access the unique part as f->name.

--
Waldek Hebisch

On 8/2/21 2:25 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 8/2/21 1:48 PM, Ian Pilcher wrote:
>>> Given the following:
>>>
>>> struct foo {
>>> /* other members */
>>
>> Note: this is a VLA unless PREFIX_SIZE is a macro that expands to an
>> integer constant expression.
>>
>>> char prefix[PREFIX_SIZE];
>
> This cannot be a VLA because VLAs are not allowed as struct or union members
You're right - I suspected that the thing he incorrectly thought was a
VLA was "name", but I wanted to cover the possibility that it was
"prefix". In my haste, I mentioned only one of the reasons (and the less
important one, to boot), why it wouldn't be one.

On 8/2/2021 1:31 PM, Keith Thompson wrote:
>
> No, gcc's extension appears to allow VLAs as struct members. This
> compiles and runs without error and, as expected, prints different
> values when it's executed again after more than a second:
>
> #include <stdio.h>
> #include <time.h>
> #include <stddef.h>
> int main(void) {
> const int size = time(NULL) % 10 + 10;
> struct s {
> char s0[size];
> char s1[size];
> char s2[size];
> };
>
> struct s obj;
>
> printf("sizeof obj = %zu\n", sizeof obj);
> printf("%zu %zu %zu\n",
> offsetof(struct s, s0),
> offsetof(struct s, s1),
> offsetof(struct s, s2));
> }
>
> (I didn't find this extension in gcc's documentation, but I didn't look
> very hard.)
>

Oh, indeed... I missed that. Thank you for pointing it out.

Interestingly, when GCC has to deal with a bunch of independent VLAs

char s0[n0];
char s1[n1];
char s2[n2];

in the generated code it typically implements them as simple individual
`char *` pointers, pointing into memory allocated by `alloca`-like
mechanism.

But once they are bundled into a struct

struct s
{
char s0[n0];
char s1[n1];
char s2[n2];
} obj;

GCC no longer has a luxury of implementing each array as an individual
pointer. It wants to maintain a flat memory layout for a struct object,
which forces it to generate code that allocates a memory buffer of size
`n0+n1+n2` and then use arithmetic on-the-fly to locate each individual
array in that buffer, e.g. to locate the beginning of `s2` it has to
calculate `n0+n1`.

In other words, the latter implementation does not come "for free": it
is markedly different from the former.

--
Best regards,
Andrey Tarasevich

On 8/2/2021 2:43 PM, Bart wrote:
> On 02/08/2021 19:27, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> BTW there is no VLA here unless PREFIX_SIZE is not a compile-time
>>> expression (and I'm not sure even then).
>>
>> If PREFIX_SIZE is not a compile time expression, it's a constraint
>> violation.  Struct and union member cannot be VLAs.  (Also, VLA support
>> is optional as of C11.)
>>
>
> This program works on gcc, tcc and lccwin:
>
> #include <stdio.h>
> int main(void) {
>     int n=100;
>     typedef struct{int xx[n];} S;
>
>     S a;
>
>     printf("sizeof(S) = %d\n",(int)sizeof(S));
> }
>
> The output is respectively 400, 8 and 32.
>
> It fails with DMC, clang, msvc and bcc (but the last two don't support
> VLAs anyway).
>

This will not likely work correctly in my compiler either, unless a
special case provision were made for the last member in a struct (the
expression would be ignored in this case).

> The mind boggles as to how it's implemented, for example with static,
> auto and heap-allocated arrays of S, or with linked lists using S nodes,
> or when S itself contains structs with such VLAs.

FWIW: My compiler (BGBCC) also supports VLAs, though only for local
variables and similar. In these contexts, they effectively decay into
pointers, and are transformed into an "alloca()" call.

Potentially, a static or global VLA could be transformed into creative
use of "realloc" or similar, or a wrapper around realloc, eg:
void __vla_globalvla(void **rptr, size_t *rsz, size_t newsz);

Which then resizes the array to be bigger if the new size exceeds the
old size, and would probably be called (potentially repeatedly) by any
function which tries to access such an array.

But, as can be noted, my compiler doesn't do anything too fancy to
support "alloca()"; in effect this gets turned by the compiler into a
special runtime call for "call malloc() and then add the returned
pointer to a linked list", and then in the epilog a function call is
added to free anything that was added to the list.

I also make no claim that multidimensional VLAs "actually work"...

Note that for normal functions with arrays, the compiler may also add
special guard tokens, and then trigger a breakpoint on function return
if these don't match their expected values. This partly helps detect if
an array overrun has occurred, but may also help detect cases where the
stack-pointer got messed up or similar.

....

My compiler also recently added lambdas, which effectively make use of
the same mechanism as "alloca()" (though does use a different runtime
call so that the returned memory can be marked as executable).

The spec for lambdas more-or-less follows the C23 proposal, but there is
an alternate syntax as well which allows for (among other things),
creating lambdas with an unbounded lifespan (though with the restriction
that they will leak memory unless manually freed).

In this case, the lambda is basically a struct, with the first 32-bytes
(at present) reserved for setting up the registers and calling into the
function body (the current stub uses 28 bytes).

The encodings used for the stub is slightly conservative, but using a
few newer encodings, it could be possible to cram it down to 12 bytes.
However, the encodings in question are not currently part of the
"baseline" ISA, and in practice this isn't likely to make much real
difference on either performance or memory footprint.

....

On 8/3/2021 8:40 AM, BGB wrote:
>
> FWIW: My compiler (BGBCC) also supports VLAs, though only for local
> variables and similar. In these contexts, they effectively decay into
> pointers, and are transformed into an "alloca()" call.
> ...
> But, as can be noted, my compiler doesn't do anything too fancy to
> support "alloca()"; in effect this gets turned by the compiler into a
> special runtime call for "call malloc() and then add the returned
> pointer to a linked list", and then in the epilog a function call is
> added to free anything that was added to the list.
>
> I also make no claim that multidimensional VLAs "actually work"...
> ...

It appears that the amount of effort you spent implementing your
pseudo-VLA would be quite sufficient to implement the standard-compliant
VLA. You just needed to channel that effort slightly differently. Which
makes one wonder why you decided to eschew the standard semantics...

--
Best regards,
Andrey Tarasevich

On 8/3/2021 11:10 AM, Andrey Tarasevich wrote:
> On 8/3/2021 8:40 AM, BGB wrote:
>>
>> FWIW: My compiler (BGBCC) also supports VLAs, though only for local
>> variables and similar. In these contexts, they effectively decay into
>> pointers, and are transformed into an "alloca()" call.
>> ...
>> But, as can be noted, my compiler doesn't do anything too fancy to
>> support "alloca()"; in effect this gets turned by the compiler into a
>> special runtime call for "call malloc() and then add the returned
>> pointer to a linked list", and then in the epilog a function call is
>> added to free anything that was added to the list.
>>
>> I also make no claim that multidimensional VLAs "actually work"...
>> ...
>
> It appears that the amount of effort you spent implementing your
> pseudo-VLA would be quite sufficient to implement the standard-compliant
> VLA. You just needed to channel that effort slightly differently. Which
> makes one wonder why you decided to eschew the standard semantics...
>

Partly it was because this was what seemed easier, and also allowed
doing pretty much all of the VLA stuff to be handled in the front-end
(things like lambdas are also handled in the frontend, as are many
operations involving "variant" types, *1, ...).

With the ABI design, variable-sized stack frames would have added more
complexity relative to fixed-size stack frames (there is no frame
pointer or similar in this case, and everything on-stack is referenced
using fixed displacements relative to the stack pointer, and
prolog/epilog adjustments use fixed offsets, ...).

Note that this is generally for a target where:
I am using 128K as the default stack size;
(Except for interrupt handlers, which use an 8K stack).
The target is (or assumes) No-MMU operation;
The RAM space is typically measured in MB.

Using malloc ends up preferable for larger memory allocations (VLAs or
large stack arrays), since it isn't bound by the stack-size limit, and
doesn't assume spending inordinate amounts of RAM on the program stacks.

Though, a few cases exist where the total RAM is measured in KB (and the
heap is just sorta wedged between ".bss" and the stack).

*1: The variant types are a non-standard extension which add dynamic
type-checking via tagged pointers; and turns pretty much every operation
on these types into a function call into the runtime.

....