linux-hardening - Re: [PATCH -next v3 1/3] lib/string_choices: Add str_true_false()/str_false

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <a6ea03c9-f92b-4faa-b924-8df58484fb13@huawei.com>
Date: Wed, 28 Aug 2024 11:49:51 +0800
From: Hongbo Li <lihongbo22@...wei.com>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: <kees@...nel.org>, <andy@...nel.org>, <trondmy@...nel.org>,
	<anna@...nel.org>, <gregkh@...uxfoundation.org>,
	<linux-hardening@...r.kernel.org>, <linux-mm@...ck.org>,
	<linux-nfs@...r.kernel.org>
Subject: Re: [PATCH -next v3 1/3] lib/string_choices: Add
 str_true_false()/str_false_true() helper



On 2024/8/28 11:22, Andrew Morton wrote:
> On Wed, 28 Aug 2024 09:48:21 +0800 Hongbo Li <lihongbo22@...wei.com> wrote:
> 
>>> This might result in copies of the strings "true" and "false" being
>>> generated for every .c file which uses this function, resulting in
>>> unnecessary bloat.
>>>
>>> It's possible that the compiler/linker can eliminate this duplication.
>>> If not, I suggest that every function in string_choices.h be uninlined.
>> The inline function is in header file, it will cause code expansion. It
>> should avoid the the copies of the strings.
> 
> Sorry, I don't understand your reply.
> 
I mean this is a inline function (and tiny enough), the compiler will do 
the code expansion and some optimizations.
> Anything which is calling these functions is not performance-sensitive,
> so optimizing for space is preferred.  An out-of-line function which
> returns a const char * will achieve this?
I think this helper can achieve this. Because it is tiny enough, the 
compiler will handle this like #define macro (do the replacement) 
without allocating extra functional stack. On the contrary, if it is 
implemented as a non-inline function, it will cause extra functional 
stack when it was called every time. And it also should be implemented 
in a source file (.c file), not in header file(.h file).

Thanks,
Hongbo