Re: Configure warning/error in m4/frexp.m4

Bruno Haible writes: > Sam James wrote: >> > It's good if you have the time to test not-yet-released compiler versions. >> > I don't have that time, and therefore will prefer to wait until the >> > clang release is out. >> >> OK. You've appreciated reports in the past (even quite recently), I

Re: Configure warning/error in m4/frexp.m4

Sam James wrote: > > It's good if you have the time to test not-yet-released compiler versions. > > I don't have that time, and therefore will prefer to wait until the > > clang release is out. > > OK. You've appreciated reports in the past (even quite recently), I can > avoid making them in

Re: Configure warning/error in m4/frexp.m4

Bruno Haible writes: > Sam James wrote: >> it's still going to be an issue if (as >> planned) Clang flips '-Wincompatible-pointer-types' to error out by >> default unless they carve out an exception for qualifiers here. >> >> I'll advocate that they do, of course. I just came across it while

Re: [PATCH] Update portability doc for CHERI, C23

On 2023-12-01 22:12, Bruno Haible wrote: Which integer types on CHERI have "holes"? intptr_t and uintptr_t, since they consume 128 bits of storage but have only 64 bits of integer value payload. Because of the holes, for example, intprops.h's TYPE_MAXIMUM doesn't work on CHERI-BSD for those

Re: Configure warning/error in m4/frexp.m4

Paul Eggert wrote: > We can conform to standard C without a cast with something like the > attached (which I haven't installed). Looks good to me. Please install it; likewise in m4/frexpf.m4. > (I assume the 'volatile' is there because of the funky things compilers > do with x86 double)

Re: Configure warning/error in m4/frexp.m4

Sam James wrote: > it's still going to be an issue if (as > planned) Clang flips '-Wincompatible-pointer-types' to error out by > default unless they carve out an exception for qualifiers here. > > I'll advocate that they do, of course. I just came across it while > checking for configure changes

Re: Configure warning/error in m4/frexp.m4

On 2023-12-01 21:52, Bruno Haible wrote: There is nothing wrong with this code (m4/frexp.m4:159, m4/frexpf.m4:83). Isn't there? I thought that the C standard doesn't let you access a 'double volatile' object via a 'void *' or 'void const *' pointer. It'd need to be 'void volatile *' or 'void

Re: [PATCH] Update portability doc for CHERI, C23

Paul Eggert wrote: > * doc/gnulib-readme.texi: > Prefer “null pointer” to “@code{NULL}” since C23 has nullptr. > (Portability guidelines): Mention C99 instead of C89 for what > Gnulib assumes of headers. > (C99 features avoided): Mention CHERI issue with intptr_t etc. > (Other portability

Re: Configure warning/error in m4/frexp.m4

Sam James writes: > Bruno Haible writes: > >> Hi Sam, > > Hi Bruno, > >> >>> The configure test in gl_FUNC_FREXP_WORKS within m4/frexp.m4 triggers >>> a Clang warning/error when Clang is passed >>> -Werror=incompatible-pointer-types. >> >> Gnulib does not support CC or CPPFLAGS or CFLAGS

Re: Configure warning/error in m4/frexp.m4

Bruno Haible writes: > Hi Sam, Hi Bruno, > >> The configure test in gl_FUNC_FREXP_WORKS within m4/frexp.m4 triggers >> a Clang warning/error when Clang is passed >> -Werror=incompatible-pointer-types. > > Gnulib does not support CC or CPPFLAGS or CFLAGS values with -Werror at > configure

Re: Configure warning/error in m4/frexp.m4

Hi Sam, > The configure test in gl_FUNC_FREXP_WORKS within m4/frexp.m4 triggers > a Clang warning/error when Clang is passed > -Werror=incompatible-pointer-types. Gnulib does not support CC or CPPFLAGS or CFLAGS values with -Werror at configure time. Neither with gcc nor with clang. The reason

Configure warning/error in m4/frexp.m4

Hi, The configure test in gl_FUNC_FREXP_WORKS within m4/frexp.m4 triggers a Clang warning/error when Clang is passed -Werror=incompatible-pointer-types. This _isn't_ an issue with GCC 14, as it doesn't consider the lost const to be a problem, like so: /tmp/foo.c: In function ‘main’:

Re: undefined-behavior obstack.c:139

On 2023-12-01 12:36, Marc Nieper-Wißkirchen wrote: It may not be a false alarm in future versions of the compiler. If that happens, Gnulib (and lots of other software) won't work in those future versions. This is so unlikely that we needn't worry about it now.

Re: undefined-behavior obstack.c:139

On Fri, Dec 01, 2023 at 05:01:45PM +0100, Bruno Haible wrote: > Jeffrey Walton wrote: > > I think that's a valid finding. NULL is not a valid address. You can't > > add anything to it. > > Can you back this opinion with citations from ISO C 23 [1] ? See N3096 (most recent draft of C23 [1]),

Re: undefined-behavior obstack.c:139

Am Fr., 1. Dez. 2023 um 21:01 Uhr schrieb Paul Eggert : > On 2023-12-01 10:40, Bruno Haible wrote: > > > Indeed, this sentence appears to forbid ((char *) NULL) + something. > > Yes. However, Gnulib code can still use ((char *) NULL) + something) > because the Gnulib portability guidelines allow

[PATCH] Update portability doc for CHERI, C23

* doc/gnulib-readme.texi: Prefer “null pointer” to “@code{NULL}” since C23 has nullptr. (Portability guidelines): Mention C99 instead of C89 for what Gnulib assumes of headers. (C99 features avoided): Mention CHERI issue with intptr_t etc. (Other portability assumptions): Say that C23 requires

Re: undefined-behavior obstack.c:139

On 2023-12-01 10:40, Bruno Haible wrote: Indeed, this sentence appears to forbid ((char *) NULL) + something. Yes. However, Gnulib code can still use ((char *) NULL) + something) because the Gnulib portability guidelines allow it. The issue with clang false positives is covered here:

Re: undefined-behavior obstack.c:139

Am Fr., 1. Dez. 2023 um 19:42 Uhr schrieb Bruno Haible : > Marc Nieper-Wißkirchen wrote: > > By 6.5.6 "Additive Operators": > > > > (2) "... one operator shall be a pointer to a complete object type..." > > > > NULL, which is a null pointer constant, is not necessarily a pointer to a > > complete

Re: undefined-behavior obstack.c:139

Marc Nieper-Wißkirchen wrote: > By 6.5.6 "Additive Operators": > > (2) "... one operator shall be a pointer to a complete object type..." > > NULL, which is a null pointer constant, is not necessarily a pointer to a > complete object type. In my test program, I used a variable of type 'char *'.

Re: undefined-behavior obstack.c:139

By 6.5.6 "Additive Operators": (2) "... one operator shall be a pointer to a complete object type..." NULL, which is a null pointer constant, is not necessarily a pointer to a complete object type. (9) "... If the pointer operand and the result do not point to elements of the same array object

Re: undefined-behavior obstack.c:139

Jeffrey Walton wrote: > I think that's a valid finding. NULL is not a valid address. You can't > add anything to it. Can you back this opinion with citations from ISO C 23 [1] ? Bruno [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf

Re: undefined-behavior obstack.c:139

On Fri, Dec 1, 2023 at 8:15 AM Bruno Haible wrote: > > [CCing bug-gnulib because obstack.c comes from gnulib.] > > Alexey Palienko wrote in > : > > > It has been built by clang 13 with "-g -fsanitize=address,undefined > >

Re: undefined-behavior obstack.c:139

[CCing bug-gnulib because obstack.c comes from gnulib.] Alexey Palienko wrote in : > It has been built by clang 13 with "-g -fsanitize=address,undefined > -fno-omit-frame-pointer -fsanitize-address-use-after-scope >

doc: Update for FreeBSD 14.0

I've updated the documentation regarding FreeBSD 14.0, as well as the maint-tools database of headers and functions. The patch [1] is quite repetitive; the interesting changes are that - The *printf functions are now up-to-date with ISO C 23. - New functions timerfd_* were added, like on

sethostname tests: Fix a compilation error on FreeBSD 14.0

On FreeBSD 14.0/x86_64, I see this compilation error in a testdir: ../../gltests/test-sethostname1.c:23:1: error: incompatible function pointer types initializing 'int (*)(const char *, size_t)' (aka 'int (*)(const char *, unsigned long)') with an expression of type 'int (const char *, int)'