Re: [PATCH 2/7] Compiler Attributes: use the no-underscores syntax

[Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>]

Hi Geert,

On Mon, Sep 3, 2018 at 8:42 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Miguel,
>
> On Sat, Sep 1, 2018 at 12:41 AM Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
>> On Sat, Sep 1, 2018 at 12:10 AM, Miguel Ojeda
>> <miguel.ojeda.sandonis@gmail.com> wrote:
>> > arch/parisc/boot/compressed/misc.c:#define malloc       malloc_gzip
>> > include/linux/decompress/mm.h:#define malloc(a) kmalloc(a, GFP_KERNEL)
>> > lib/inflate.c:#define malloc(a) kmalloc(a, GFP_KERNEL)
>> > include/linux/compiler_types.h:#define noinline_for_stack noinline
>> > include/linux/raid/pq.h:#define noinline __attribute__((noinline))
>> > tools/include/linux/compiler.h:#define noinline
>> > arch/mips/sgi-ip27/ip27-reset.c:#define noreturn while(1);
>>
>> A better list, searching for all attributes used anywhere in the kernel:
>>
>> git grep -E '^\s*#define\s+(address_space|alias|aligned|always_inline|assume_aligned|bitwise|bnd_legacy|cold|common|const|constructor|context|deprecated|designated_init|destructor|error|externally_visible|flatten|force|format|format|gnu_inline|hot|hotpatch|indirect_branch|latent_entropy|long_call|malloc|may_alias|mode|model|naked|nocast|noclone|noderef|noinline|no_instrument_function|nonnull|no_randomize_layout|noreturn|no_sanitize_address|optimize|packed|pure|randomize_layout|regparm|require_context|safe|section|syscall_linkage|target|tls_model|unused|used|user|vector_size|visibility|warning|warn_unused_result|weak)(\(|\s|$)'
>>
>> arch/mips/sgi-ip27/ip27-reset.c:#define noreturn while(1);
>>                  /* Silence gcc.  */
>> arch/parisc/boot/compressed/misc.c:#define malloc       malloc_gzip
>> arch/powerpc/xmon/ansidecl.h:#define    const
>> drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:#define error(fmt,
>> args...) bioslog(ERROR, fmt, ##args)
>> include/linux/compiler_attributes.h:#define   noinline
>> __attribute__((noinline))
>> include/linux/decompress/mm.h:#define malloc(a) kmalloc(a, GFP_KERNEL)
>> include/linux/raid/pq.h:#define noinline __attribute__((noinline))
>> lib/inflate.c:#define malloc(a) kmalloc(a, GFP_KERNEL)
>> tools/include/linux/compiler-gcc.h:#define  noinline
>> __attribute__((noinline))
>> tools/include/linux/compiler.h:#define noinline
>> tools/testing/selftests/futex/include/logging.h:#define error(message,
>> err, args...) \
>>
>> None of these should make a problem. And it would may avoid people
>> using such common-name-macros in the future ;-)
>
> That's very fragile.
> Who knows all (current and future) attribute names by heart, and that defining
> them could have such side effects?

Please see the email I sent after that one -- I clarified that this
was more about the current state and that in v3 it will be changed, if
only to avoid surprises in the future for ourselves. I agree with you
and, as Rasmus pointed out, we will use the macros anyway.

>
> At least "alias", "force", "format", "mode", "model", "optimize", "target" are
> names I wouldn't hesitate to use as a macro name in a driver...

A macro with a lowercase, short & common name is not the best idea in
my opinion; if only because of clarity for future readers. Unless it
really improved the code readability for some reason in a particular
case, I would avoid it. But to each his own! :-)

Thanks for reviewing!

Cheers,
Miguel