Re: ISO C 23, , and once_flag

effrey Walton wrote: > Be careful of call_once. > > Several years ago I cut over to C++11's call_once. The problem was, it > only worked reliably on 32-bit and 64-bit Intel platforms. It was a > disaster on Aarch64, PowerPC and Sparc. I had to back it out. > > The problems happened back when GCC

Re: Support FALLTHROUGH macro better in glibc+clang

On 2023-03-25 14:24, Paul Eggert wrote:    # if __GNUC_PREREQ (7,0) || __glibc_has_attribute (__fallthrough__) Come to think of it this could be simplified further, to just: # if __glibc_has_attribute (__fallthrough__) since GCC started supporting __has_attribute in GCC 5.

Re: Support FALLTHROUGH macro better in glibc+clang

On 2023-02-26 08:43, Bruno Haible wrote: -# if __GNUC__ >= 7 +# if (__GNUC__ >= 7) || (__clang_major__ >= 10) Sorry I didn't see this earlier. Since this is protected by #ifdef _LIBC" it might be better to do this the glibc way. Something like the following, perhaps? # if __GNUC_PREREQ (

Re: ISO C 23, , and once_flag

On Sat, Mar 25, 2023 at 5:05 PM Bruno Haible wrote: > > In ISO C 23, > - the type 'once_flag', > - the macro ONCE_FLAG_INIT, > - the declaration of function 'call_once' > are all available from , not only from . > > 1) This makes it clear that often call_once is needed in an application > wi

Re: Support FALLTHROUGH macro better in glibc+clang

Hi Paul, Any objections against this proposed patch from ? > 2023-02-26 Bruno Haible > > Support FALLTHROUGH macro better in glibc+clang. > * lib/fnmatch.c (FALLTHROUGH): Use __attribute__ ((__fallthrough__)) >

ISO C 23, , and once_flag

In ISO C 23, - the type 'once_flag', - the macro ONCE_FLAG_INIT, - the declaration of function 'call_once' are all available from , not only from . 1) This makes it clear that often call_once is needed in an application without also needing mutexes. For this reason, I'm moving the 'call_once

stdio: ISO C 23: Define _PRINTF_NAN_LEN_MAX

ISO C 23 specifies a new macro, to be defined in : _PRINTF_NAN_LEN_MAX. This patch implements it. 2023-03-25 Bruno Haible stdio: ISO C 23: Define _PRINTF_NAN_LEN_MAX. * lib/stdio.in.h (_PRINTF_NAN_LEN_MAX): New macro. * m4/stdio_h.m4 (gl_STDIO_H): Invoke gl_MUSL_LIBC.

Make some header file tests a bit stronger

When testing a header file, let's check whether all required macros are defined before including any other header file. This makes the tests somewhat stronger. 2023-03-25 Bruno Haible Make some header file tests a bit stronger. * tests/test-float.c: Include fpucw.h and macros.

is* tests: Ensure needed .m4 files are packaged

This patch ensures that some tests modules have the .m4 files that they need, not only indirectly by coincidence, but explicitly. 2023-03-25 Bruno Haible is* tests: Ensure needed .m4 files are packaged. * modules/isfinite-tests (Files): Add m4/exponent*.m4. * modules/i

Re: RFC: add a string-desc module

On 2023-03-25 04:49, Bruno Haible wrote: I'll add a comment regarding printf with the "%.*s" directive. That works only if the string lacks NULs and its length fits into int, and one must also convert the idx_t length to int (e.g., via a cast which I find tricky). Although these limitations

Re: RFC: add a string-desc module

Hello! I frequently use ad-hoc code for this, however in library code, in which xmalloc is not much used. I learn new gnulib things primarily from the manual. Do you plan to document it there? Le vendredi 24 mars 2023 à 22:50 +0100, Bruno Haible a écrit : > /* Return a copy of string S, as a NUL

Re: Bug report

Davin Pearson wrote: > davin@davins:~/Downloads/m4-1.4.19$ sudo make install > ... > make[1]: Leaving directory '/home/davin/Downloads/m4-1.4.19' > davin@davins:~/Downloads/m4-1.4.19$ So, the installation succeeded. > davin@davins:~/Public/sources/50webs-com$ make m4 > TARGET_DIR=./../../targets/

Re: Bug report

> CC c-stack.o > In file included from /usr/include/signal.h:328, > from ./signal.h:52, > from c-stack.c:49: > c-stack.c:55:27: error: missing binary operator before token "(" >55 | #elif HAVE_LIBSIGSEGV && (SIGSTKSZ < 16384) > |

Bug report

davin@davins:~/Downloads/m4-1.4.18$ sudo make install make install-recursive make[1]: Entering directory '/home/davin/Downloads/m4-1.4.18' Making install in . make[2]: Entering directory '/home/davin/Downloads/m4-1.4.18' make[3]: Entering directory '/home/davin/Downloads/m4-1.4.18' make[3]: Nothin

Re: RFC: add a string-desc module

Vivien Kraus wrote: > I frequently use ad-hoc code for this, however in library code, in > which xmalloc is not much used. Good point. I'll need to duplicate the interface of the memory allocating functions: one with 'x', that use xmalloc, and one without 'x', for use in libraries. > I learn new

Re: RFC: add a string-desc module

Le vendredi 24 mars 2023 à 19:20 -0400, Jeffrey Walton a écrit : >  The type that I'm proposing does not have NUL byte appended to the > data > > always and automatically, because I think it is more important to > > have a > > string_desc_substring function that does not cause memory > > allocation

Re: RFC: add a string-desc module

Paul Eggert wrote: > >struct > >{ > > size_t nbytes; > > char * data; > >} > > One minor comment: use idx_t instead of size_t, for the usual reasons. Right, done. Thanks for the reminder. > Also it might be a bit more efficient to put the pointer first. On some CPUs probab

Re: RFC: add a string-desc module

Jeffrey Walton wrote: > A natural thing to want > to do is print a string, and C-based routines usually expect a > terminating NULL. I'll add a comment regarding printf with the "%.*s" directive. > Also, if you initialize the struct, then the allocated string will > likely include a terminating N