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
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Mon, Feb 21, 2022 at 01:22:53PM -0500, 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?
GCC 11 (gcc-11.2.1-9.fc35.x86_64) gives plenty of errors with this code:
array.c: In function ‘f’: array.c:14:8: error: cast specifies array type 14 | (char [])(char *)memcpy(malloc((size)*sizeof(char)), | ^ array.c:13:16: error: invalid use of flexible array member 13 | arg1->bar = | ^ array.c:17:16: error: invalid use of flexible array member 17 | arg1->bar = 0; | ^
In fact these are identical in GCC 12 (gcc-12.0.1-0.6.fc36.x86_64).
So whatever it is, I don't think it has anything to do with GCC 12.
I wonder if this code was meant to be compiled with an unusual -std flag? (I tried -std=c90 and it seems to make no difference.)
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?
Rich.
On Monday, February 21, 2022 2:58:43 PM EST Richard W.M. Jones wrote:
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?
GCC 11 (gcc-11.2.1-9.fc35.x86_64) gives plenty of errors with this code:
array.c: In function ‘f’: array.c:14:8: error: cast specifies array type 14 | (char [])(char *)memcpy(malloc((size)*sizeof(char)), | ^
array.c:13:16: error: invalid use of flexible array member 13 | arg1->bar = | ^
array.c:17:16: error: invalid use of flexible array member 17 | arg1->bar = 0; | ^
In fact these are identical in GCC 12 (gcc-12.0.1-0.6.fc36.x86_64).
So whatever it is, I don't think it has anything to do with GCC 12.
Thanks. You got me wondering what's going on. It builds fine on F35. So, I looked at the kernel headers on F35. It has bar[0]; F36/rawhide have bar[]; So, the kernel changed. Checking the blame info, it was related to
https://github.com/KSPP/linux/issues/78
OK, so now I know what happened. I guess I need to check with SWIG upstream. Or rewrite the Python bindings to get rid of SWIG. Either way, it's going to be a while to fix this FTBFS.
And as the other email mentions...I bet it is making buggy code.
-Steve