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?
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 theDo you think it makes sense to add this a flag that enables -Werror=format
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.
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?
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).
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.
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?
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
On Mon, Jun 10, 2024 at 04:24:54PM +0200, Guillem Jover wrote:
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).
Another related question: if not via dpkg-buildflags, how do we do
rebuilds with changed default flags?
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?
Another related question: if not via dpkg-buildflags, how do we do
rebuilds with changed default flags?
Ideally, we'd not just do a rebuild with the flags, but also do a
rebuild without and then compare the binary .debs. In the event that we misguide configure, we expect the .debs to differ and otherwise to equal
due to the work of the reproducible builds folks. That equality has a
really annoying difference in practice though: Build ids are dependent
on the compiler flags, so the comparison would have to magically ignore changes in build id and this is where things become quite difficult.
Ideally, we'd not just do a rebuild with the flags, but also do a
rebuild without and then compare the binary .debs. In the event that we misguide configure, we expect the .debs to differ and otherwise to equal
due to the work of the reproducible builds folks. That equality has a
really annoying difference in practice though: Build ids are dependent
on the compiler flags, so the comparison would have to magically ignore changes in build id and this is where things become quite difficult.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 360 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 128:34:19 |
| Calls: | 7,686 |
| Files: | 12,828 |
| Messages: | 5,711,088 |