public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Oliver Neukum <oneukum@suse.com>
To: "Tomasz Pakuła" <tomasz.pakula.oficjalny@gmail.com>,
	"Oliver Neukum" <oneukum@suse.com>
Cc: jikos@kernel.org, bentiss@kernel.org, anssi.hannula@gmail.com,
	linux-input@vger.kernel.org, linux-usb@vger.kernel.org,
	oleg@makarenk.ooo
Subject: Re: [PATCH v5 02/12] HID: pidff: Do not send effect envelope if it's empty
Date: Tue, 21 Jan 2025 14:01:22 +0100	[thread overview]
Message-ID: <88f81117-a7a5-417b-87d1-a443732c59bc@suse.com> (raw)
In-Reply-To: <CAFqprmzt2+dngxVDEiLNmR1AmjU0d0AvsebrSz0Y9w23BJ+8Aw@mail.gmail.com>

On 21.01.25 11:17, Tomasz Pakuła wrote:
> On Tue, 21 Jan 2025 at 10:59, Oliver Neukum <oneukum@suse.com> wrote:
>> I am afraid this is the most convoluted piece of boolean algebra I've seen
>> in a long time. In particular because it mixes things that do not belong together.
> 
> Could you elaborate on that? What here does not belong?

Hi,

> 
> I think the diff is a bit unfortunate and doesn't make it justice, but
> this is based on
> code that was already there. Instead of just checking if the new
> values differ from
> old values, we first check if any values are different from 0. If
> neither are != 0 OR
> the effect didn't contain an envelope previously (NULL here), we
> return the value
> of the check.

Indeed. And that is the problem.
You could see the evaluation to contain either two or three main cases.

First view:

A - everything is 0. We return false.
B - we compare the old and the new and return the comparison. With a subcase
of no old old values existing.

In the first view you are mixing the test for no old values of the second case
with the test for no old values existing.

Or you split up the second condition into two independent cases.


[..]
> 
>          if (!needs_new_envelope || !old)
>                  return needs_new_envelope;

This boolean statement stems from a common result, not from a common
logical reason for acting so. This is clear because if the first half
is true, you are returning itself.

This statement would be so much more clear as:

if (!needs_new_envelope)
	return false;

if (!old)
	return needs_new_envelope;

	Regards
		Oliver



  reply	other threads:[~2025-01-21 13:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-19 13:12 [PATCH v5 00/12] HID: Upgrade the generic pidff driver and add hid-universal-pidff Tomasz Pakuła
2025-01-19 13:12 ` [PATCH v5 01/12] HID: pidff: Convert infinite length from Linux API to PID standard Tomasz Pakuła
2025-01-19 13:12 ` [PATCH v5 02/12] HID: pidff: Do not send effect envelope if it's empty Tomasz Pakuła
2025-01-21  9:59   ` Oliver Neukum
2025-01-21 10:17     ` Tomasz Pakuła
2025-01-21 13:01       ` Oliver Neukum [this message]
2025-01-21 13:15         ` Tomasz Pakuła
2025-01-19 13:12 ` [PATCH v5 03/12] HID: pidff: Clamp PERIODIC effect period to device's logical range Tomasz Pakuła
2025-01-19 13:12 ` [PATCH v5 04/12] HID: pidff: Add MISSING_DELAY quirk and its detection Tomasz Pakuła
2025-01-19 13:12 ` [PATCH v5 05/12] HID: pidff: Add MISSING_PBO " Tomasz Pakuła
2025-01-19 13:12 ` [PATCH v5 06/12] HID: pidff: Add MISSING_DEVICE_CONTROL quirk Tomasz Pakuła
2025-01-19 13:12 ` [PATCH v5 07/12] HID: pidff: Add hid_pidff_init_with_quirks and export as GPL symbol Tomasz Pakuła
2025-01-19 13:12 ` [PATCH v5 08/12] HID: pidff: Add FIX_WHEEL_DIRECTION quirk Tomasz Pakuła
2025-01-19 13:13 ` [PATCH v5 09/12] HID: pidff: Stop all effects before enabling actuators Tomasz Pakuła
2025-01-21 10:10   ` Oliver Neukum
2025-01-21 13:18     ` Tomasz Pakuła
2025-01-22  1:37     ` Tomasz Pakuła
2025-01-19 13:13 ` [PATCH v5 10/12] HID: Add hid-universal-pidff driver and supported device ids Tomasz Pakuła
2025-01-19 13:13 ` [PATCH v5 11/12] MAINTAINERS: Add entry for hid-universal-pidff driver Tomasz Pakuła
2025-01-19 13:13 ` [PATCH v5 12/12] HID: pidff: Add PERIODIC_SINE_ONLY quirk Tomasz Pakuła

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=88f81117-a7a5-417b-87d1-a443732c59bc@suse.com \
    --to=oneukum@suse.com \
    --cc=anssi.hannula@gmail.com \
    --cc=bentiss@kernel.org \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=oleg@makarenk.ooo \
    --cc=tomasz.pakula.oficjalny@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox