This idiom is known as “flexible array member,” and it is standardized since C99. The “bar[0]” syntax you mention is a GCC extension predating C99.
I’m not that familiar with the nuances of SWIG, but it looks like SWIG doesn’t understand this at all, and is treating “bar” as a pointer member and adding a nonsense (char []) cast. “bar” needs to be the target of a memcpy/memmove, not a pointer assignment. Given this, I wonder if it even generates appropriate code for the “bar[0]” version, or if it just emits a zero-length memcpy.
At first glance, and without doing any experiments of my own, I would say that, unless there’s something in SWIG that just needs to be configured differently, it certainly appears to be a SWIG bug. If so, it may be nontrivial to fix.
I wonder if this was always a little bit broken, and GCC 12 just revealed it with better diagnostics.
– Ben
On Mon, Feb 21, 2022, at 1:22 PM, Steve Grubb wrote:
> Hello,
>
> I have a FTBFS package, audit, that has a strange problem that I'd like to
> run by the devel list. It is a common idiom in the kernel to do something
> like:
>
> struct foo{
> unsigned int barlen;
> char bar[];
> };
>
> There are about 80 instances of this in the kernel headers. When one of these
> headers is included by SWIG, it makes code like this:
>
> if (arg2) {
> arg1->bar = (char [])(char *)memcpy(malloc((size)*sizeof(char)), (const
> char *)(arg2), sizeof(char)*(size));
> } else {
> arg1->bar = 0;
> }
>
> which results in
>
> error: cast specifies array type
>
> and
>
> error: assignment to expression with array type.
>
> Is this intended to be an error by gcc-12?
>
> One fix is to change the struct decalaration to bar[0]; and gcc doesn't error
> out on that. But that will take some time to get in the upstream kernel. Just
> curious if this is intended by gcc or a problem of SWIG/kernel?
>
> Thanks,
> -Steve
>
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
