Subject: bug#70898: switching to <stdbit.h> for Emacs bit ops

From: Paul Eggert <[email-masked]>
Date: Mon, 13 May 2024 09:56:46 -0700

On 2024-05-13 07:34, Mattias Engdegård wrote:
> Has C23 been frozen yet? The most recent accessible draft I could find was N3096.

It's not final, but it's pretty frozen. I doubt whether the stdbit spec 
will change.

Yes, n3096 is the latest public draft.

> Overall happy with the changes but haven't read them in detail.
> Minor things I stumbled upon:
> 
>> @@ -4269,7 +4263,9 @@ endif
>>   ## begin gnulib module verify
>>   ifeq (,$(OMIT_GNULIB_MODULE_verify))
>>   
>> +ifneq (,$(gl_GNULIB_ENABLED_verify_CONDITION))
>>   
>> +endif
> 
> Unfinished work?

That was generated automatically by gnulib-tool and is harmless. That 
being said, I installed a change to the Gnulib stdbit module for other 
reasons (porting to theoretical platforms where C integers are wider 
than 256 bits!) here:

https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=9768940fbd11558b8dab3453aa419a3433933d50

and I expect that will remove the harmless code by removing the 
conditional dependency on Gnulib's assert-h module.

>> +/* 1 if supported, -1 if not, 0 if unknown.  */
>> +extern signed char __gl_stdint_popcount_support;
> 
> `__gl_stdbit_popcount_support`, maybe?

Thanks, fixed here:

https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=9deb8e8891e36968deeb93bd666670f7950d1095

> (By the way, in case you are on the WG: the N3096 draft has

Yes, that text is weird and I also didn't have a clue as to what it 
meant. So I cloned latest glibc+gcc behavior and hoped for the best.

I have avoided dealing with that WG for decades as my political skills, 
such as they are, are better deployed elsewhere. But you're welcome to 
file a bug report.