Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240419134535.GJ4163@brightrain.aerifal.cx>
Date: Fri, 19 Apr 2024 09:45:35 -0400
From: Rich Felker <dalias@...c.org>
To: Nihal Jere <nihal@...aljere.xyz>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] change __volatile to __volatile__ for consistency

On Wed, Apr 17, 2024 at 10:10:17PM -0500, Nihal Jere wrote:
> ---
> These look like the only two occurences of "__volatile" in musl,
> elsewhere "__volatile__" is used.
> 
>  arch/x32/atomic_arch.h    | 2 +-
>  arch/x86_64/atomic_arch.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x32/atomic_arch.h b/arch/x32/atomic_arch.h
> index 918c2d4e..eef253db 100644
> --- a/arch/x32/atomic_arch.h
> +++ b/arch/x32/atomic_arch.h
> @@ -44,7 +44,7 @@ static inline void a_or(volatile int *p, int v)
>  #define a_and_64 a_and_64
>  static inline void a_and_64(volatile uint64_t *p, uint64_t v)
>  {
> -	__asm__ __volatile(
> +	__asm__ __volatile__(
>  		"lock ; and %1, %0"
>  		 : "=m"(*p) : "r"(v) : "memory" );
>  }
> diff --git a/arch/x86_64/atomic_arch.h b/arch/x86_64/atomic_arch.h
> index da4e2037..8753b700 100644
> --- a/arch/x86_64/atomic_arch.h
> +++ b/arch/x86_64/atomic_arch.h
> @@ -53,7 +53,7 @@ static inline void a_or(volatile int *p, int v)
>  #define a_and_64 a_and_64
>  static inline void a_and_64(volatile uint64_t *p, uint64_t v)
>  {
> -	__asm__ __volatile(
> +	__asm__ __volatile__(
>  		"lock ; and %1, %0"
>  		 : "=m"(*p) : "r"(v) : "memory" );
>  }
> -- 
> 2.43.0

This is probably okay since it's just these two places and these files
are very low-churn to begin with, but in general, "improve
consistency/style" patches are not what we're looking for in musl.

A big value of the project is low "churn" -- that is, files don't get
modified unless there's a strong need to modify them to achieve some
important goal, like fixing a bug, adding new mandatory or highly
wanted functionality, significantly improving performance, etc. This
both makes it possible for humans reading the project commit log to
catch bugs or suspicious changes (because there's a very high signal
to noise ratio), and gives folks using older versions the best chance
of being able to apply bugfix patches with no added work fixing
conflicts.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.