netdev - Re: [PATCH net-next 2/4] s390/lcs: Convert sprintf to scnprintf

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: <4ae0428a-feec-e78e-f0f7-c08493959e74@linux.ibm.com>
Date: Wed, 21 Jun 2023 15:49:06 +0200
From: Alexandra Winter <wintera@...ux.ibm.com>
To: Simon Horman <simon.horman@...igine.com>
Cc: David Miller <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>,
        netdev@...r.kernel.org, linux-s390@...r.kernel.org,
        Heiko Carstens <hca@...ux.ibm.com>,
        Thorsten Winkler
 <twinkler@...ux.ibm.com>,
        Jules Irenge <jbi.octave@...il.com>
Subject: Re: [PATCH net-next 2/4] s390/lcs: Convert sprintf to scnprintf


On 20.06.23 21:16, Simon Horman wrote:
> On Tue, Jun 20, 2023 at 10:34:09AM +0200, Alexandra Winter wrote:
>> From: Thorsten Winkler <twinkler@...ux.ibm.com>
>>
>> This LWN article explains the rationale for this change
>> https: //lwn.net/Articles/69419/
>> Ie. snprintf() returns what *would* be the resulting length,
>> while scnprintf() returns the actual length.
> Hi Alexandra,
> 
> Although I agree that it's nice to use scnprintf() the justification given
> seems a bit odd: it talks of the return value but it is ignored both before
> and after this patch.
> 
> Likewise for some of the changes in patch 4/4.


You are correct. The main improvement of these patches is to get rid of sprintf.
And we decided to use scnprintf everywhere. I'll send a v2 with a slightly
updated description.


> 
> Also is it intentional that there is a space in the URL immediately
> after 'http:' ? Maybe mangled by something. Not that it really maters
> AFAIC.


Thanks for spotting this, Simon. Corrected in v2.