Hi! On Mon, 2024-06-10 at 16:06:13 +0500, Andrey Rakhmatullin wrote: > On Mon, Jun 10, 2024 at 07:48:59AM +0200, Helmut Grohne wrote: > > > We recently increased the time_t size on certain architectures and some > > > packages started failing to build because they were using a format > > > specifier too narrow for the wider time_t, e.g. #1067829. > > > But the only reason those package FTBFS is they enable either -Werror or > > > some more specific non-default switch like -Werror=format=2, so I suspect > > > much more packages contain similar code but gained only a warning. Isn't > > > this a bad thing? Should we enable at least some combination of -Wformat* > > > switches by default? Should we at least add a new flag to dpkg-buildflags > > > and do some test rebuilds with it enabled? > > > > It wasn't quite clear to me what -Werror=format=2 actually means. > > According to the gcc documentation[1], -Wformat=2 currently means: > > > > -Wformat -Wformat-nonliteral -Wformat-security -Wformat-y2k.
Those are in addition to the ones enabled by -Wformat=1, which are: -Wnonnull -Wno-format-contains-nul -Wno-format-extra-args -Wno-format-zero-length So all the above would supposedly turn into -Werror too. > But I don't know if even -Werror=format is too much to enable by default > globally (I assume it's a good thing to enable it, though). Hard to say w/o a rebuild I guess. (And take into account this can also affect configure-style checks, which might become silent errors but end up disabling features or enabling unexpected code paths or similar.) In general I think it's good (in principle) to enable -Werror flags that detect actual bugs in code, the problem is always going to be the amount of fallout and work that creates, and whether there's consensus about that work commitment being acceptable to maintainers in Debian, or whether that can interfere with transitions going on, etc. > > It also is unclear how this impacts the archive and yes, I'd recommend a > > rebuild. Note though that we likely need this rebuild both on a 64bit > > architecture and a 32bit architecture that is not i386 (due to how t64 > > works). A partial archive rebuild may work to gauge the size of the > > problem. > > > > I note that this kind of change affects cross builds, so performing > > cross builds for armhf on amd64 will likely show many of these failures > > (in addition to all the regular cross build failures). > > > > I recommend doing more research before moving forward with this. In > > particular a MBF about introduced problems would be prudent before doing > > the switch and even if we don't switch, such a MBF bears value on its > > own. > Do you think it makes sense to add this a flag that enables -Werror=format > to dpkg-buildflags(1), before, or after a test rebuild, before, or after > the MBF if we do one? If by adding you mean adding a new feature flag that is disabled by default, then depending on the feature area, that might unfortunately be equivalent to enable it by default (due to the «all» keyword). (I started a design to version the build flags interface, but I got stuck, so I let it brew as a background process, have pending to finish that up and propose it on d-dpkg.) Thanks, Guillem
