Thread (68 messages) 68 messages, 21 authors, 2021-04-20

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

From: Finn Thain <hidden>
Date: 2020-11-22 22:55:16
Also in: alsa-devel, amd-gfx, bridge, ceph-devel, dm-devel, intel-gfx, intel-wired-lan, keyrings, linux-acpi, linux-arm-msm, linux-block, linux-can, linux-cifs, linux-crypto, linux-ext4, linux-fbdev, 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-usb, linux-watchdog, linux-wireless, lkml, netdev, netfilter-devel, op-tee, selinux, target-devel, xen-devel

On Sun, 22 Nov 2020, Miguel Ojeda wrote:
It isn't that much effort, isn't it? Plus we need to take into account 
the future mistakes that it might prevent, too.
We should also take into account optimisim about future improvements in 
tooling.
So even if there were zero problems found so far, it is still a positive 
change.
It is if you want to spin it that way.
I would agree if these changes were high risk, though; but they are 
almost trivial.
This is trivial:

 case 1:
	this();
+	fallthrough;
 case 2:
 	that();

But what we inevitably get is changes like this:

 case 3:
        this();
+       break;
 case 4:
        hmmm();

Why? Mainly to silence the compiler. Also because the patch author argued 
successfully that they had found a theoretical bug, often in mature code.

But is anyone keeping score of the regressions? If unreported bugs count, 
what about unreported regressions?
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