mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Chunhui He <hchunhui@mail.ustc.edu.cn>,
	Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] dma/pool: trivial: add semicolon after label attributes
Date: Tue, 29 Aug 2023 15:22:22 +0100	[thread overview]
Message-ID: <6f936d6e-9f27-ba72-68de-0ed27c0dbbe1@arm.com> (raw)
In-Reply-To: <20230826085317.69713-1-hchunhui@mail.ustc.edu.cn>

On 26/08/2023 9:53 am, Chunhui He wrote:
> The gcc document says label attributes are ambiguous if they are
> not immediately followed by a semicolon. Although the ambiguity
> does not arise in C90/99, it would be better to add it.

AFAICS, what that clearly says is that *C++* label attributes can be 
ambiguous. This is not C++ code. Even in C11, declarations still cannot 
be labelled, so it should still be the case that, per the same GCC 
documentation, "the ambiguity does not arise". And even if the language 
did allow it, an inline declaration at that point at the end of a 
function would be downright weird and against the kernel coding style 
anyway.

So, I don't really see what's "better" about cluttering up C code with 
unnecessary C++isms; it's just weird noise to me. The only thing I think 
it *does* achieve is introduce the chance that the static checker 
brigade eventually identifies a redundant semicolon and we get more 
patches to remove it again.

Thanks,
Robin.

> Link: https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Label-Attributes-2
> Signed-off-by: Chunhui He <hchunhui@mail.ustc.edu.cn>
> ---
>   kernel/dma/pool.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
> index 1acec2e22827..f99f02b88c40 100644
> --- a/kernel/dma/pool.c
> +++ b/kernel/dma/pool.c
> @@ -136,7 +136,7 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
>   #ifdef CONFIG_DMA_DIRECT_REMAP
>   	dma_common_free_remap(addr, pool_size);
>   #endif
> -free_page: __maybe_unused
> +free_page: __maybe_unused;
>   	__free_pages(page, order);
>   out:
>   	return ret;

  reply	other threads:[~2023-08-29 14:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-26  8:53 Chunhui He
2023-08-29 14:22 ` Robin Murphy [this message]
2023-08-29 15:12   ` Christoph Hellwig
2023-08-29 15:28     ` Robin Murphy
2023-08-31 11:59       ` Chunhui He
2023-09-01  8:56         ` Robin Murphy
2023-09-01  8:59           ` Robin Murphy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6f936d6e-9f27-ba72-68de-0ed27c0dbbe1@arm.com \
    --to=robin.murphy@arm.com \
    --cc=hch@lst.de \
    --cc=hchunhui@mail.ustc.edu.cn \
    --cc=iommu@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®