On 19/08/2024 18:23, Yavor Doganov wrote:
GCC 14 promoted certain warnings to errors but these do not affect Objective-C packages. The GNU Objective-C compiler does not define __STDC_VERSION__ meaning that the C standard in effect is gnu89: -Wimplicit-function-declaration [1], -Wincompatible-pointer-types, etc. remain just warnings. (FWIW, clang does the opposite: it sets -std=gnu11 for Objective-C code but even with -std=gnu17 these remain just warnings.)I have rebuilt 64 packages (62 GNUstep + 2 non-GNUstep) with -std=gnu17 and the result was 15 FTBFS bugs. I attach a list with the affected packages at the end of the message. Can we have authoritative answers from a relase team member to the following questions: A. Should we consider these bugs and if so, what severity? B. If the answer to A is positive, should we enforce -std=gnu17 when building Objective-C code to align with the C world [2]? Of course this would mean that these bugs will become RC as soon as the change lands in unstable. C. If the answer to B is positive, which is the most suitable package to enforce the standard: * gnustep-make (either as DEB_OBJCFLAGS_MAINT_APPEND definition in /usr/share/GNUstep/debian/config.mk or injecting -std=gnu17 in the rules). Not all GNUstep packages use gnustep-make and of course non-GNUstep Objective-C packages don't. * dpkg (in OBJCFLAGS). Not all packages honor dpkg's buildflags although these cases should be considered bugs, IMHO. * GCC?
We (the RT) don't set that kind of policy. That should be up to the Obj-C toolchain maintainers together with the rest of the ecosystem. To me it sounds like a good thing to enable some of those warnings by default.
I'd suggest to bring dpkg and GCC maintainers into the loop once there's consensus that the standard is to be bumped.
Cheers, Emilio
