-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libfdt: Replace deprecated 0-length arrays with proper flexible arrays #76
Conversation
Replace the 0-length arrays in structures with proper flexible arrays. This will avoid warnings when building under GCC 13 with -fstrict-flex-arrays, which the Linux kernel will be doing soon: In file included from ../lib/fdt_ro.c:2: ../lib/../scripts/dtc/libfdt/fdt_ro.c: In function 'fdt_get_name': ../lib/../scripts/dtc/libfdt/fdt_ro.c:319:24: warning: 'strrchr' reading 1 or more bytes from a region of size 0 [-Wstringop-overread] 319 | leaf = strrchr(nameptr, '/'); | ^~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Kees Cook <keescook@chromium.org>
It seems like the freebsd tests have been failing for a while, looking at the recent commits. |
Hrm, so, using standard constructs is good. It's particularly good for I had avoided this, because I was under the impression that flexible array elements counted as length 1, rather than 0 for the purposes of If you can double check that with a definitive source, that would be most helpful. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you can double check that with a definitive source, that would be most helpful.
Quoting C99 §6.7.2.1 "Structure and union specifiers" ¶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 flexible array member . In most situations,
the flexible array member is ignored. In particular, the size of the structure is as if the
flexible array member were omitted except that it may have more trailing padding than
the omission would imply.
Thanks. Applied. |
This change is breaking the build of pylibfdt for me: I'm using gcc 12.2.0. |
Uhm, is that some kind of SWIG binding? We've seen issues with non-C scrapers falling over in the face of flex arrays before: https://www.spinics.net/lists/fedora-devel/msg297996.html |
Yes, it's SWIG. Paging @sjg20 ... Looks like the distro fixes are either reverting the change or avoiding the struct for SWIG. Will see if we can do the latter. |
Yes it breaks for me too...will take a quick look |
https://stackoverflow.com/questions/29781102/swig-handling-tlvzero-length-array Hmm I think reverting is the best.. Kees are you able to figure out the swig stuff and resubmit? |
(and how did this pass for you?) |
I have a fix: %rename(fdt_property) fdt_property_func; +%ignore fdt_property::data;
|
Seems right. We don't need to set these through the swig interface anyway |
Patch on the list. Note that it passed CI tests, so I guess Python is skipped for those. |
Funny that that one went to spam |
@robherring @sjg20 the reason I didn't detect this breakage is that the build of pylibfdt has been broken for me for months. It's cleearly not broken for everyone, so it must be something specific to my build environment (Fedora 37), but I don't know how to fix it. In any case I've now applied the fix. |
Replace the 0-length arrays in structures with proper flexible arrays. This will avoid warnings when building under GCC 13 with -fstrict-flex-arrays, which the Linux kernel will be doing soon:
In file included from ../lib/fdt_ro.c:2:
../lib/../scripts/dtc/libfdt/fdt_ro.c: In function 'fdt_get_name': ../lib/../scripts/dtc/libfdt/fdt_ro.c:319:24: warning: 'strrchr' reading 1 or more bytes from a region of size 0 [-Wstringop-overread]
319 | leaf = strrchr(nameptr, '/');
| ^~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Kees Cook keescook@chromium.org