Re: new modules for libunistring metadata

On 2/20/24 6:10 PM, Bruno Haible wrote: > For my feeling, there's too little added value in such a macro. > > Remember the costs of documenting a function or macro: > - The user needs more time to read the documentation. > - The developer needs to code and document it. Fair enough. I assume t

Re: new modules for libunistring metadata

Collin Funk wrote: > Would it make sense to provide a macro to check if the current version > is greater than or equal to a given version? Or should that just be left > up to whoever wants to use this variable. Why is there no macro #define streq(a,b) (strcmp (a, b) == 0) in ? Because it can be

Re: new modules for libunistring metadata

On 2/20/24 4:15 PM, Bruno Haible wrote: > It's better if this metadata is generated from gen-uni-tables.c. This > eliminates a manual step. These patches do it. Would it make sense to provide a macro to check if the current version is greater than or equal to a given version? Or should that just b

new modules for libunistring metadata

The next version of GNU libunistring will define more metadata. Suggested by Roger Crew in . If this metadata is maintained in libunistring, it has to be updated each time we upgrade to a new Unicode version, in the future

Re: syntax-check rule to silence -Winclude-next-absolute-path warning

Collin Funk wrote: > > The full list of header files for which #include "..." is to be avoided is: > > > > alloca.h > > arpa_inet.h > > assert.h > > I saw that arpa_inet.h had an underscore instead of a slash in this > message but forgot to fix it when I pasted it into the Makefile... There were

Re: syntax-check rule to silence -Winclude-next-absolute-path warning

On 2/18/24 4:44 AM, Bruno Haible wrote: > The full list of header files for which #include "..." is to be avoided is: > > alloca.h > arpa_inet.h > assert.h I saw that arpa_inet.h had an underscore instead of a slash in this message but forgot to fix it when I pasted it into the Makefile... Sorry

printf with %n directives

In I wrote: > I cannot guarantee that Gnulib will be able to support %n > in the long run. The "security-aware community" are filing CVEs here and > there; %n is among their targets (it has already been disabled from libc > on U

Re: syntax-check rule to silence -Winclude-next-absolute-path warning

Simon Josefsson wrote: > There are some checks that I struggle to understand the point of, > and one that I simply disagree with (sc_prohibit_strcmp). Likewise for me. [1] > Having a link > to discussion helps to determine how to deal with errors. > > What do you think about: > >1) using a

*printf-posix: Avoid crash in a configure test

After configuring my dev environment to leave core dumps in /var/crash, I see that a 'configure' run in a testdir of all of gnulib produces one core dump, and I get a UI notification of it. The cause is the test program that tests whether *printf supports the %n directive: it triggers an abort(), w