On Mon, Dec 03, 2012 at 07:57:33PM +0100, Behan Webster wrote:Fair enough. That works too.However, in order to approximate what gcc is doing in code, obviouslyWhy hide? The thing that is done here is setting up pointers and keep this
some math is required. The thought was that macros would hide the
worst of it, trying not to obfuscate what was actually being done.
struct as a container. It is never used again, just freed. Therefore I would
suggest to remove and do something different.
Which is all good in the case of the gadget code.I've been profiling some sample code around this implementationI'm not concerned about speed here. This is an one time setup.
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.
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.But certainly if anyone has a solution which works for everyone, thenThat is nice to hear. Besides gcc there is the icc.
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,
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.VLAIS is not something they are willing to accept (for variousIs this not described in C99 18.104.22.168p16?
reasons). There are other patches to LLVM that are still working
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.
2 A structure or union shall not contain a member with incomplete or function type (hence,From C99 22.214.171.124 p4:
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.
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.
I hope so too. But like the Linux kernel community, the LLVM community have standards and procedures for getting code accepted which take time.their way upstream that are required to be able to compile Linux asI hope the other are "simple" to get in :)