Thread (65 messages) 65 messages, 19 authors, 2020-12-08

Re: [PATCH 000/141] Fix fall-through warnings for Clang

From: Miguel Ojeda <hidden>
Date: 2020-11-26 17:06:22
Also in: alsa-devel, amd-gfx, bridge, ceph-devel, dm-devel, dri-devel, intel-gfx, intel-wired-lan, keyrings, linux-acpi, linux-arm-msm, linux-block, linux-can, linux-cifs, linux-crypto, linux-ext4, linux-gpio, linux-hardening, linux-hwmon, linux-i3c, linux-ide, linux-iio, linux-input, linux-integrity, linux-media, linux-mediatek, linux-mm, linux-mmc, linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp, linux-security-module, linux-usb, linux-watchdog, linux-wireless, lkml, netdev, netfilter-devel, op-tee, selinux, target-devel, virtualization, xen-devel

On Thu, Nov 26, 2020 at 4:28 PM Geert Uytterhoeven [off-list ref] wrote:
The maintainer is not necessarily the owner/author of the code, and
thus may not know the intent of the code.
Agreed, I was not blaming maintainers -- just trying to point out that
the problem is there :-)

In those cases, it is still very useful: we add the `fallthrough` and
a comment saying `FIXME: fallthrough intended? Figure this out...`.
Thus a previous unknown unknown is now a known unknown. And no new
unknown unknowns will be introduced since we enabled the warning
globally.
BTW, you cannot mindlessly fix the latter, as you cannot know if
"(a == b)" or "((a = b))" was intended, without understanding the code
(and the (possibly unavailable) data sheet, and the hardware, ...).
That's right, I was referring to the cases where the compiler saves
someone time from a typo they just made.

Cheers,
Miguel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help