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. > > Of these, we already enable -Werror=format-security, but not the other > ones. It is not clear to me, which of these actually catches the the > type mismatches. Would you do more research here?
#include <stdio.h>
void foo()
{
printf("%d", 0L);
}
This produces a warning with just -Wformat ("format ‘%d’ expects argument
of type ‘int’, but argument 2 has type ‘long int’ [-Wformat=]"). It
doesn't look like any more narrow options for this exist (-Wno-* ones
listed in the -Wformat description don't silence this one, and they don't
look like they should anyway).
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).
> 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?
--
WBR, wRAR
signature.asc
Description: PGP signature
