From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4916 invoked from network); 24 May 2023 22:12:22 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 24 May 2023 22:12:22 -0000 Received: (qmail 19865 invoked by uid 550); 24 May 2023 22:12:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 19817 invoked from network); 24 May 2023 22:12:18 -0000 Date: Wed, 24 May 2023 18:12:05 -0400 From: Rich Felker To: Jens Gustedt Cc: musl@lists.openwall.com Message-ID: <20230524221205.GF4163@brightrain.aerifal.cx> References: <1fe28ea2525f112264a1a819d8ce50a97504ab8b.1684932892.git.Jens.Gustedt@inria.fr> <20230524212835.GC4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230524212835.GC4163@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [C23 new stdlib 2/4] C23: add the memalignment function On Wed, May 24, 2023 at 05:28:35PM -0400, Rich Felker wrote: > On Wed, May 24, 2023 at 09:38:52PM +0200, Jens Gustedt wrote: > > The name is reserved, so we don't need to protect it via a feature > > macro or a weak symbol. > > --- > > include/stdlib.h | 3 +++ > > src/stdlib/memalignment.c | 6 ++++++ > > 2 files changed, 9 insertions(+) > > create mode 100644 src/stdlib/memalignment.c > > > > diff --git a/include/stdlib.h b/include/stdlib.h > > index 7800074d..68993c04 100644 > > --- a/include/stdlib.h > > +++ b/include/stdlib.h > > @@ -178,6 +178,9 @@ long double strtold_l(const char *__restrict, char **__restrict, struct __locale > > typedef int once_flag; > > void call_once(once_flag *, void (*)(void)); > > > > +size_t (memalignment)(const void *); > > +#define memalignment(P) (((size_t)1)<<__builtin_ctzll((unsigned long long)P)) > > + > > #ifdef __cplusplus > > } > > #endif > > diff --git a/src/stdlib/memalignment.c b/src/stdlib/memalignment.c > > new file mode 100644 > > index 00000000..58b68954 > > --- /dev/null > > +++ b/src/stdlib/memalignment.c > > @@ -0,0 +1,6 @@ > > +#include > > + > > +size_t (memalignment)(const void *p) > > +{ > > + return memalignment(p); > > +} > > -- > > 2.34.1 > > There's a more efficient implementation of this function which does > not depend on __builtin_ctzll (which we don't): p^(p-1)&p > > I'm not clear that there's a really good motivation for having it > implemented in the header. It kinda falls under the "maybe do it > because it's easy" case, but once you switch to the non-GNUC-specific > version, it needs a static inline function to avoid multiple > evaluation, and then it gets to the point of "this is really too much > code to have in a header" (which is more an issue of avoiding > "creative" content in headers than anything else). I was reading the spec and came across: "If p is a null pointer, an alignment of zero is returned." and: "NOTE An alignment of zero indicates that the tested pointer cannot be used to access an object of any type." I think this precludes your version with ctzll, but works fine with the replacement I proposed. Rich