Re: [PATCH V2 2/3] Remove VLAIS usage from gadget code

From: Behan Webster
Date: Tue Dec 04 2012 - 18:50:17 EST

On 12-12-04 11:24 PM, Sebastian Andrzej Siewior wrote:
On Mon, Dec 03, 2012 at 07:57:33PM +0100, Behan Webster wrote:
However, in order to approximate what gcc is doing in code, obviously
some math is required. The thought was that macros would hide the
worst of it, trying not to obfuscate what was actually being done.
Why hide? The thing that is done here is setting up pointers and keep this
struct as a container. It is never used again, just freed. Therefore I would
suggest to remove and do something different.
Fair enough. That works too.

I've been profiling some sample code around this implementation
comparing it between compilers, and it approximates the code size and
speed of using VLAIS in gcc (especially with -O2). It actually
performs better than the previously proposed macros.
I'm not concerned about speed here. This is an one time setup.
Which is all good in the case of the gadget code.

However VLAIS is used in other places too where code size and speed are very important. The proposal was for something which might be used for more than just the gadget code. VLAIS is used in only a handful of places in the kernel. They just happen to be in important parts of the kernel which was why the approach was to change as little as necessary.

But certainly if anyone has a solution which works for everyone, then
I'm more than happy to adopt it. The LLVM community has made quite a
few changes in order to help get Linux working with clang. However,
That is nice to hear. Besides gcc there is the icc.
Lots of people have brought up icc. Although in the same breath most also say nobody is using it anymore. However, I have no idea whether that is true. The difference is that clang is widely available in most distros; icc is not.

VLAIS is not something they are willing to accept (for various
reasons). There are other patches to LLVM that are still working
Is this not described in C99
You're thinking of "Flexible Array Members". Essentially the last element in a structure can be the equivalent of a zero length array; something which both gcc and clang support today.

From C99
16 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 ïexible array member. In most situations,
the ïexible array member is ignored. In particular, the size of the structure is as if the
ïexible array member were omitted except that it may have more trailing padding than
the omission would imply. Howev er, when a . (or ->) operator has a left operand that is
(a pointer to) a structure with a ïexible 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 ïexible 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 undeïned if any attempt is made to access that
element or to generate a pointer one past it.

However if we're considering the C99 standard, it also explicitly disallows the use of VLAs in structs (VLAIS).

From C99 p2:
2 A structure or union shall not contain a member with incomplete or function type (hence,
a structure shall not contain an instance of itself, but may contain a pointer to an instance
of itself), except that the last member of a structure with more than one named member
may have incomplete array type; such a structure (and any union containing, possibly
recursively, a member that is such a structure) shall not be a member of a structure or an
element of an array.
From C99 p4:
4 If the size is not present, the array type is an incomplete type. <snip>
Essentially all arrays in a structure must not be variable length except the last member of the array which can be a zero length array (which can be used to approximate a VLA at the end). It also says that a struct which uses a flexible array member can't be used inside another struct.

their way upstream that are required to be able to compile Linux as
I hope the other are "simple" to get in :)
I hope so too. But like the Linux kernel community, the LLVM community have standards and procedures for getting code accepted which take time.



Behan Webster

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at