lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87sejg6shn.wl-tiwai@suse.de>
Date: Tue, 01 Jul 2025 13:49:24 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Thorsten Blum <thorsten.blum@...ux.dev>
Cc: Takashi Iwai <tiwai@...e.de>,	Jaroslav Kysela <perex@...ex.cz>,	Takashi
 Iwai <tiwai@...e.com>,	Uwe Kleine-König
 <u.kleine-koenig@...libre.com>,	linux-sound@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ALSA: mips/hal2: Refactor and improve hal2_compute_rate()

On Tue, 01 Jul 2025 12:18:44 +0200,
Thorsten Blum wrote:
> 
> On 1. Jul 2025, at 11:25, Takashi Iwai wrote:
> > IMHO, this doesn't look improving the code readability than the
> > original code.  And the generated code doesn't seem significantly
> > better, either.
> 
> I didn't look at the generated code, but I think the patch definitely
> improves the function (not necessarily its runtime, but its readability
> and maintainability).
> 
> I think the patch primarily improves maintainability by eliminating the
> magic number '4' that was scattered throughout the function. Now the
> scaling factor is assigned once to the semantically more meaningful
> variable 'codec->inc' and used consistently.
> 
> It also improves consistency by using 'codec->master' when calculating
> 'codec->mod' instead of repeating the constants '44100' and '48000'.
> 
> Additionally, it removes the unnecessary local variable 'mod' and the
> 'rate' update, making the function more concise (4 vs 12 lines).

The line length doesn't matter.  It's a small code.  And it's no
hot-path, and no common code used by many drivers, either.
That is, the only question is how better the code is readable.
And, often a simple if-block can be easier to follow the code flow --
that's your case, too.

In anyway, this is really really minor issue and we shouldn't waste
too much time just for this kind of optimization. 


thanks,

Takashi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ