linux-kernel - Re: optimizing out inline functions

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: <87lk1trdr8.fsf@saeurebad.de>
Date:	Thu, 29 May 2008 05:27:23 +0200
From:	Johannes Weiner <hannes@...urebad.de>
To:	James Kosin <jkosin@...a.intcomgrp.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: optimizing out inline functions

Hi,

James Kosin <jkosin@...a.intcomgrp.com> writes:

> Sam Ravnborg wrote:
>> On Wed, May 28, 2008 at 02:51:02PM -0500, Steve French wrote:
>>> In trying to remove some macros, I ran across another kernel style
> <<--SNIP-->>
>> With reference to a recent thread about kconfig
>> I would prefer:
>> static inline void some_debug_function(var1)
>> {
>> 	if (KCONFIG_DEBUG_SOMETHING) {
>> 		something = var1;
>> 		printk(some debug text);
>> 	}
>> }
>>
>>
>> But we do not have KCONFIG_DEBUG_SOMETHING available
>> so the second best is to use an empty function
>> to keep the typechecking in place.
>>
>> IIRC gcc optimize both away.
>
> Another way would be to have:
>
> static inline void some_debug_function(var1)
> {
>    #ifdef KCONFIG_DEBUG_SOMETHING
>       something = var1;
>       printk(some debug text);
>    #endif
> }
>
> BUT, this probably violates some styling rules.

Without indenting the ifdefs, I think this solution is the best.

It gives you the advantages of type checking but saves a superfluous
prototype.

	Hannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/