Re: [RFC PATCH 00/78] Strict disable implicit fallthrough

2023-10-16 Thread Manos Pitsidianakis
On Mon, 16 Oct 2023, 18:04 Peter Maydell,  wrote:

> On Mon, 16 Oct 2023 at 15:58, Manos Pitsidianakis
>  wrote:
> >
> > Hello Peter,
> >
> > On Mon, 16 Oct 2023, 17:13 Peter Maydell, 
> wrote:
> >>
> >> On Fri, 13 Oct 2023 at 13:42, Markus Armbruster 
> wrote:
> >> >
> >> > Emmanouil Pitsidianakis  writes:
> >> >
> >> > > Hello,
> >> > >
> >> > > This RFC is inspired by the kernel's move to
> -Wimplicit-fallthrough=3
> >> > > back in 2019.[0]
> >> > > We take one step (or two) further by increasing it to 5 which
> rejects
> >> > > fall through comments and requires an attribute statement.
> >> > >
> >> > > [0]:
> >> > >
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a035d552a93b
> >> > >
> >> > > The line differences are not many, but they spread all over
> different
> >> > > subsystems, architectures and devices. An attempt has been made to
> split
> >> > > them in cohesive patches to aid post-RFC review. Part of the RFC is
> to
> >> > > determine whether these patch divisions needs improvement.
> >> > >
> >> > > Main questions this RFC poses
> >> > > =
> >> > >
> >> > > - Is this change desirable and net-positive.
> >> >
> >> > Unwanted fallthrough is an easy mistake to make, and
> >> > -Wimplicit-fallthrough=N helps avoid it.  The question is how far up
> we
> >> > need to push N.  Right now we're at N=2.  Has unwanted fallthrough
> been
> >> > a problem?
> >>
> >> Mmm, this is my opinion I think. We have a mechanism for
> >> catching "forgot the 'break'" already (our =2 setting) and
> >> a way to say "intentional" in a fairly natural way (add the
> >> comment). Does pushing N up any further gain us anything
> >> except a load of churn?
> >>
> >> Also, the compiler is not the only thing that processes our
> >> code: Coverity also looks for "unexpected fallthrough" issues,
> >> so if we wanted to switch away from our current practice we
> >> should check whether what we're switching to is an idiom
> >> that Coverity recognises.
> >
> >
> > It is a code style change as the cover letter mentions, it's not related
> to the static analysis itself.
>
> Yes, exactly. As a code style change it needs a fairly high level
> of justification for the code churn, and the cover letter
> doesn't really provide one...
>


As I state in the cover letter, I personally find that using one macro
instead of a comment regex feels more consistent. But your view is valid as
well!

Let's consider the RFC retracted then.

--
Manos

>


Re: [RFC PATCH 00/78] Strict disable implicit fallthrough

2023-10-16 Thread Peter Maydell
On Mon, 16 Oct 2023 at 15:58, Manos Pitsidianakis
 wrote:
>
> Hello Peter,
>
> On Mon, 16 Oct 2023, 17:13 Peter Maydell,  wrote:
>>
>> On Fri, 13 Oct 2023 at 13:42, Markus Armbruster  wrote:
>> >
>> > Emmanouil Pitsidianakis  writes:
>> >
>> > > Hello,
>> > >
>> > > This RFC is inspired by the kernel's move to -Wimplicit-fallthrough=3
>> > > back in 2019.[0]
>> > > We take one step (or two) further by increasing it to 5 which rejects
>> > > fall through comments and requires an attribute statement.
>> > >
>> > > [0]:
>> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a035d552a93b
>> > >
>> > > The line differences are not many, but they spread all over different
>> > > subsystems, architectures and devices. An attempt has been made to split
>> > > them in cohesive patches to aid post-RFC review. Part of the RFC is to
>> > > determine whether these patch divisions needs improvement.
>> > >
>> > > Main questions this RFC poses
>> > > =
>> > >
>> > > - Is this change desirable and net-positive.
>> >
>> > Unwanted fallthrough is an easy mistake to make, and
>> > -Wimplicit-fallthrough=N helps avoid it.  The question is how far up we
>> > need to push N.  Right now we're at N=2.  Has unwanted fallthrough been
>> > a problem?
>>
>> Mmm, this is my opinion I think. We have a mechanism for
>> catching "forgot the 'break'" already (our =2 setting) and
>> a way to say "intentional" in a fairly natural way (add the
>> comment). Does pushing N up any further gain us anything
>> except a load of churn?
>>
>> Also, the compiler is not the only thing that processes our
>> code: Coverity also looks for "unexpected fallthrough" issues,
>> so if we wanted to switch away from our current practice we
>> should check whether what we're switching to is an idiom
>> that Coverity recognises.
>
>
> It is a code style change as the cover letter mentions, it's not related to 
> the static analysis itself.

Yes, exactly. As a code style change it needs a fairly high level
of justification for the code churn, and the cover letter
doesn't really provide one...

thanks
-- PMM



Re: [RFC PATCH 00/78] Strict disable implicit fallthrough

2023-10-16 Thread Manos Pitsidianakis
Hello Peter,

On Mon, 16 Oct 2023, 17:13 Peter Maydell,  wrote:

> On Fri, 13 Oct 2023 at 13:42, Markus Armbruster  wrote:
> >
> > Emmanouil Pitsidianakis  writes:
> >
> > > Hello,
> > >
> > > This RFC is inspired by the kernel's move to -Wimplicit-fallthrough=3
> > > back in 2019.[0]
> > > We take one step (or two) further by increasing it to 5 which rejects
> > > fall through comments and requires an attribute statement.
> > >
> > > [0]:
> > >
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a035d552a93b
> > >
> > > The line differences are not many, but they spread all over different
> > > subsystems, architectures and devices. An attempt has been made to
> split
> > > them in cohesive patches to aid post-RFC review. Part of the RFC is to
> > > determine whether these patch divisions needs improvement.
> > >
> > > Main questions this RFC poses
> > > =
> > >
> > > - Is this change desirable and net-positive.
> >
> > Unwanted fallthrough is an easy mistake to make, and
> > -Wimplicit-fallthrough=N helps avoid it.  The question is how far up we
> > need to push N.  Right now we're at N=2.  Has unwanted fallthrough been
> > a problem?
>
> Mmm, this is my opinion I think. We have a mechanism for
> catching "forgot the 'break'" already (our =2 setting) and
> a way to say "intentional" in a fairly natural way (add the
> comment). Does pushing N up any further gain us anything
> except a load of churn?
>
> Also, the compiler is not the only thing that processes our
> code: Coverity also looks for "unexpected fallthrough" issues,
> so if we wanted to switch away from our current practice we
> should check whether what we're switching to is an idiom
> that Coverity recognises.
>

It is a code style change as the cover letter mentions, it's not related to
the static analysis itself.

--
Manos

>


Re: [RFC PATCH 00/78] Strict disable implicit fallthrough

2023-10-16 Thread Peter Maydell
On Fri, 13 Oct 2023 at 13:42, Markus Armbruster  wrote:
>
> Emmanouil Pitsidianakis  writes:
>
> > Hello,
> >
> > This RFC is inspired by the kernel's move to -Wimplicit-fallthrough=3
> > back in 2019.[0]
> > We take one step (or two) further by increasing it to 5 which rejects
> > fall through comments and requires an attribute statement.
> >
> > [0]:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a035d552a93b
> >
> > The line differences are not many, but they spread all over different
> > subsystems, architectures and devices. An attempt has been made to split
> > them in cohesive patches to aid post-RFC review. Part of the RFC is to
> > determine whether these patch divisions needs improvement.
> >
> > Main questions this RFC poses
> > =
> >
> > - Is this change desirable and net-positive.
>
> Unwanted fallthrough is an easy mistake to make, and
> -Wimplicit-fallthrough=N helps avoid it.  The question is how far up we
> need to push N.  Right now we're at N=2.  Has unwanted fallthrough been
> a problem?

Mmm, this is my opinion I think. We have a mechanism for
catching "forgot the 'break'" already (our =2 setting) and
a way to say "intentional" in a fairly natural way (add the
comment). Does pushing N up any further gain us anything
except a load of churn?

Also, the compiler is not the only thing that processes our
code: Coverity also looks for "unexpected fallthrough" issues,
so if we wanted to switch away from our current practice we
should check whether what we're switching to is an idiom
that Coverity recognises.

thanks
-- PMM



Re: [RFC PATCH 00/78] Strict disable implicit fallthrough

2023-10-13 Thread Daniel P . Berrangé
On Fri, Oct 13, 2023 at 03:51:22PM +0300, Manos Pitsidianakis wrote:
> On Fri, 13 Oct 2023 11:14, "Daniel P. Berrangé"  wrote:
> > On Fri, Oct 13, 2023 at 10:47:04AM +0300, Emmanouil Pitsidianakis wrote:
> > > 
> > > Main questions this RFC poses
> > > =
> > > 
> > > - Is this change desirable and net-positive.
> > 
> > Yes, IMHO it is worth standardizing on use of the attribute. The allowed
> > use of comments was a nice thing by the compiler for coping with 
> > pre-existing
> > code, but using the attribute is best long term for a consistent style.
> > 
> > > - Should the `fallthrough;` pseudo-keyword be defined like in the Linux
> > >   kernel, or use glib's G_GNUC_FALLTHROUGH, or keep the already existing
> > >   QEMU_FALLTHROUGH macro.
> > 
> > As a general rule, if glib provides functionality we aim o use that
> > and not reinvent the wheel. IOW, we should just use G_GNUC_FALLTHROUGH.
> 
> I agree. My reasoning was:
> 
> - The reinvented wheel is only an attribute and not a big bunch of NIH  code

It isn't just about the amount of code, it is the familiarity of the
code. QEMU's codebase is glib based, by using glib functionality we
leverage developers' general familiarity with / knowledge of glib,
as opposed to custom QEMU approaches which need learning.

> - The macro def in glib depends on the glib version you use

If we need to depend on something that is newer than our min glib version,
then we add back compat definitino to 'include/glib-compat.h' for the older
version.

> - G_GNUC_FALLTHROUGH looks kind of abrasive to my eye, while  `fallthrough`
> blends in with other switch keywords like break.

My impression seeing this series, was exactly the opposite. I did not
like 'fallthrough' blending in with the rest of code, and also did not
like that it is a macro in lowercase, thus hiding that it is a macro

> - C23 standardises fallthrough. We might not ever support C23 but it's  good
> to be consistent with standards and other, larger projects (linux  kernel).

We're at least a decade away from being able to use anything from C23.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|




Re: [RFC PATCH 00/78] Strict disable implicit fallthrough

2023-10-13 Thread Manos Pitsidianakis

On Fri, 13 Oct 2023 11:14, "Daniel P. Berrangé"  wrote:

On Fri, Oct 13, 2023 at 10:47:04AM +0300, Emmanouil Pitsidianakis wrote:


Main questions this RFC poses
=

- Is this change desirable and net-positive.


Yes, IMHO it is worth standardizing on use of the attribute. The allowed
use of comments was a nice thing by the compiler for coping with pre-existing
code, but using the attribute is best long term for a consistent style.


- Should the `fallthrough;` pseudo-keyword be defined like in the Linux
  kernel, or use glib's G_GNUC_FALLTHROUGH, or keep the already existing
  QEMU_FALLTHROUGH macro.


As a general rule, if glib provides functionality we aim o use that
and not reinvent the wheel. IOW, we should just use G_GNUC_FALLTHROUGH.


I agree. My reasoning was:

- The reinvented wheel is only an attribute and not a big bunch of NIH 
 code

- The macro def in glib depends on the glib version you use
- G_GNUC_FALLTHROUGH looks kind of abrasive to my eye, while 
 `fallthrough` blends in with other switch keywords like break.
- C23 standardises fallthrough. We might not ever support C23 but it's 
 good to be consistent with standards and other, larger projects (linux 
 kernel).


I think these (except for myself finding G_GNUC_FALLTHROUGH ugly) make a 
strong case for not using the glib macro, personally. I'd be interested 
to know if there is a counterpoint to it: because I don't want this 
change to cause problems in the future.



Manos



Re: [RFC PATCH 00/78] Strict disable implicit fallthrough

2023-10-13 Thread BALATON Zoltan

On Fri, 13 Oct 2023, Emmanouil Pitsidianakis wrote:

Hello,

This RFC is inspired by the kernel's move to -Wimplicit-fallthrough=3
back in 2019.[0]
We take one step (or two) further by increasing it to 5 which rejects
fall through comments and requires an attribute statement.

[0]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a035d552a93b

The line differences are not many, but they spread all over different
subsystems, architectures and devices. An attempt has been made to split
them in cohesive patches to aid post-RFC review. Part of the RFC is to
determine whether these patch divisions needs improvement.

Main questions this RFC poses
=

- Is this change desirable and net-positive.


IMO current fall through comments are OK. This new way does not improve it 
much because it adds one more peculiarity new people have to get used to. 
Adding a fall through comment when one gets a warning is something one 
easily can figure out but finding out there's a macro for that would need 
consulting docs.



- Should the `fallthrough;` pseudo-keyword be defined like in the Linux
 kernel, or use glib's G_GNUC_FALLTHROUGH, or keep the already existing
 QEMU_FALLTHROUGH macro.


If there'w already QEMU_FALTHROUGH why not use that? Looks more obvious 
than a macro that looks like a strange function or keyword. Then a check 
could be added to checkpatch.pl to tell people to used QEMU_FALLTHROUGH 
istead of a fall through comment (matching the same regexp gcc accepts as 
others will already be checked by gcc) to enforce its usage.



- Should fallthrough comments be removed if they do not include extra
 information.


If this change is considered useful and not just code churn then replace 
comments, don't leave both as then the comment do not add any info.



Some external resources
===

See the RFC discussion in the kernel:

https://lore.kernel.org/lkml/1d2830aadbe9d8151728a7df5b88528fc72a0095.1564549413.git@perches.com/

The `fallthrough;` pseudo-keyword in the kernel source code:

https://elixir.bootlin.com/linux/latest/C/ident/fallthrough

In summary, I quote the doc comment and definition:

   /*
* Add the pseudo keyword 'fallthrough' so case statement blocks
* must end with any of these keywords:
*   break;
*   fallthrough;
*   continue;
*   goto ;
*   return [expression];
*
*  gcc: 
https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html#Statement-Attributes
*/
   #if __has_attribute(__fallthrough__)
   # define fallthrough__attribute__((__fallthrough__))
   #else
   # define fallthroughdo {} while (0)  /* fallthrough */


Is the empty loop needed here? If the compiler does not mind a semicolon 
after a comment then there could be a semicolon as an empty statement 
there too. But maybe there are some cases where this would be needed, just 
curious why it's there in this case?


Regards,
BALATON Zoltan


   #endif

Background - Motivation
===

The C switch statement allows you to conditionally goto different labels
depending on a value. A break; statement conveniently goto's the end of
the switch. If a "case" does not end in a break, we say that the control
flow falls through the next case label, if any, implicitly. This can
lead to bugs and QEMU uses the GCC warning -Wimplicit-fallthrough to
prevent this.

Currently, QEMU is built with -Wimplicit-fallthrough=2. This makes GCC's
static analyzer check for a case-insensitive matches of the .*falls?[
\t-]*thr(ough|u).* regular expression. This means the following list of
comments taken from QEMU all disable the implicit fallthrough warning:

- /* FALLTHRU */
- /* fall through */
- /* Fall through.  */
- /* Fall through... */
- /* fall through if hEventTimeout is signaled */
- /* FALL THROUGH */

To keep a constistent code style, this commit adds a macro `fallthrough`
that looks like a C keyword but expands to an attribute statement in
supported compilers (GCC at the moment).

Note: there was already such a macro, QEMU_FALLTHROUGH, and it was used
only around 7 times in the code base. The first commit replaces it.

Emmanouil Pitsidianakis (78):
 include/qemu/compiler.h: replace QEMU_FALLTHROUGH with fallthrough
 block: add fallthrough pseudo-keyword
 fpu/softfloat: add fallthrough pseudo-keyword
 qapi/opts-visitor: add fallthrough pseudo-keyword
 qobject/json: add fallthrough pseudo-keyword
 tcg: add fallthrough pseudo-keyword
 hw/virtio/virtio-balloon.c: add fallthrough pseudo-keyword
 hw/block: add fallthrough pseudo-keyword
 hw/acpi/aml-build.c: add fallthrough pseudo-keyword
 hw/ide/atapi.c: add fallthrough pseudo-keyword
 hw/timer: add fallthrough pseudo-keyword
 hw/usb: add fallthrough pseudo-keyword
 hw/adc: add fallthrough pseudo-keyword
 util/error-report.c: add fallthrough pseudo-keyword
 accel/tcg: add fallthrough pseudo-keyword
 audio: add fallthrough pseudo-keyword
 

Re: [RFC PATCH 00/78] Strict disable implicit fallthrough

2023-10-13 Thread Daniel P . Berrangé
On Fri, Oct 13, 2023 at 10:47:04AM +0300, Emmanouil Pitsidianakis wrote:
> 
> Main questions this RFC poses
> =
> 
> - Is this change desirable and net-positive.

Yes, IMHO it is worth standardizing on use of the attribute. The allowed
use of comments was a nice thing by the compiler for coping with pre-existing
code, but using the attribute is best long term for a consistent style.

> - Should the `fallthrough;` pseudo-keyword be defined like in the Linux
>   kernel, or use glib's G_GNUC_FALLTHROUGH, or keep the already existing
>   QEMU_FALLTHROUGH macro.

As a general rule, if glib provides functionality we aim o use that
and not reinvent the wheel. IOW, we should just use G_GNUC_FALLTHROUGH.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|