All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael Büsch" <m@bues.ch>
To: Rand Deeb <rand.sec96@gmail.com>
Cc: deeb.rand@confident.ru, jonas.gorski@gmail.com,
	khoroshilov@ispras.ru, kvalo@kernel.org,
	linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
	lvc-project@linuxtesting.org,
	voskresenski.stanislav@confident.ru, james.dutton@gmail.com
Subject: Re: [PATCH v3] ssb: Fix potential NULL pointer dereference in ssb_device_uevent
Date: Fri, 8 Mar 2024 06:09:43 +0100	[thread overview]
Message-ID: <20240308060943.2410ef2e@barney> (raw)
In-Reply-To: <20240307232927.171197-1-rand.sec96@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2421 bytes --]

On Fri,  8 Mar 2024 02:29:27 +0300
Rand Deeb <rand.sec96@gmail.com> wrote:

> On Fri, Mar 8, 2024 at 12:39 AM Michael Büsch <m@bues.ch> wrote:
> 
> > The point is that leaving them in is defensive programming against future changes
> > or against possible misunderstandings of the situation.  
> 
> Dear Michael, I understand your point. It's essential to consider defensive
> programming principles to anticipate and mitigate potential issues in the 
> future. However, it's also crucial to strike a balance and not overburden 
> every function with excessive checks. It's about adopting a mindset of 
> anticipating potential problems while also maintaining code clarity and 
> efficiency.

Removing NULL checks is the opposite of maintainability and code clarity.
Efficiency doesn't matter here. (And besides that, NULL checks do not always mean less efficiency.)

> > A NULL pointer dereference is Undefined Behavior.
> > It can't get much worse in C.  
> 
> Again, If we adopt this approach, we'll find ourselves adding a null check 
> to every function we write, assuming that such changes may occur in the 
> future.

This would be a good thing.
Let the compiler remove redundant checks or let them stay there in the resulting
program, if the compiler can't fiure it out.
Checks are a good thing.

> > Your suggestion was about REMOVING a null pointer check.
> > Not about adding one.
> > I NAK-ed the REMOVAL of a null pointer check. Not the addition.  
> 
> My suggestion was to remove a (REDUNDANT) null pointer check, and not a 
> null pointer check, there is a big difference.

No. There is no difference.

> However, if the reviewer encounters this check, they 
> might mistakenly assume that 'dev' could indeed be NULL before the function
> call.

So? Nothing would happen.

> Conversely, if they read that 'dev' cannot be NULL, it could lead to 
> confusion, and perhaps they want the actual null check. Removing redundant 
> checks could mitigate confusion and minimize the risk of overlooking the 
> actual null check for example.

I fundamentally disagree.
Removing a NULL check _adds_ confusion.
NULL is "the billion mistake" of computing.
Please don't ever make it worse.
Thanks.

I will not ack a patch that reduces code quality.
Removing NULL checks almost always reduces the quality of the code.

-- 
Michael Büsch
https://bues.ch/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2024-03-08  5:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-06 12:30 [PATCH v3] ssb: Fix potential NULL pointer dereference in ssb_device_uevent Rand Deeb
2024-03-06 15:54 ` Jeff Johnson
2024-03-06 19:51 ` Jonas Gorski
2024-03-07 13:41   ` Rand Deeb
2024-03-07 18:24     ` Michael Büsch
2024-03-07 21:19       ` Rand Deeb
2024-03-07 21:38         ` Michael Büsch
2024-03-07 22:02           ` James Dutton
2024-03-08  4:50             ` Michael Büsch
2024-03-07 23:29           ` Rand Deeb
2024-03-08  1:04             ` James Dutton
2024-03-08 12:11               ` Rand Deeb
2024-03-08  5:09             ` Michael Büsch [this message]
2024-03-08 11:36               ` Rand Deeb
2024-03-08 15:44                 ` Michael Büsch
2024-03-12 15:31 ` [v3] ssb: Fix potential NULL pointer dereference in ssb_device_uevent() Kalle Valo

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=20240308060943.2410ef2e@barney \
    --to=m@bues.ch \
    --cc=deeb.rand@confident.ru \
    --cc=james.dutton@gmail.com \
    --cc=jonas.gorski@gmail.com \
    --cc=khoroshilov@ispras.ru \
    --cc=kvalo@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lvc-project@linuxtesting.org \
    --cc=rand.sec96@gmail.com \
    --cc=voskresenski.stanislav@confident.ru \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.