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 <[email protected]>
> ---
> 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;
On Tue, Aug 29, 2023 at 03:22:22PM +0100, Robin Murphy wrote:
> 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.
Agreed. Even more importantly that attribute looks rather questionable
to start with as it can be dropped by just moving the #endif a little:
diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
index 1acec2e228273f..da03c4a57cebe3 100644
--- a/kernel/dma/pool.c
+++ b/kernel/dma/pool.c
@@ -135,8 +135,8 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
remove_mapping:
#ifdef CONFIG_DMA_DIRECT_REMAP
dma_common_free_remap(addr, pool_size);
+free_page:
#endif
-free_page: __maybe_unused
__free_pages(page, order);
out:
return ret;