Re: CodeQL warning about returning stack-allocated memory in gettext.h

On Tue, Nov 14, 2023 at 8:14 PM Bruno Haible wrote: > > Hi, > > Eric Gallager wrote: > > Hi, I have a project that uses gnulib's gettext.h, and also has CodeQL > > scanning turned on in GitHub. In this project, CodeQL warns about the > > "return translation;" statement on line 247 of gettext.h, sa

Re: CodeQL warning about returning stack-allocated memory in gettext.h

Hi, Eric Gallager wrote: > Hi, I have a project that uses gnulib's gettext.h, and also has CodeQL > scanning turned on in GitHub. In this project, CodeQL warns about the > "return translation;" statement on line 247 of gettext.h, saying that > it "May return stack-allocated memory from msg_ctxt_id

CodeQL warning about returning stack-allocated memory in gettext.h

Hi, I have a project that uses gnulib's gettext.h, and also has CodeQL scanning turned on in GitHub. In this project, CodeQL warns about the "return translation;" statement on line 247 of gettext.h, saying that it "May return stack-allocated memory from msg_ctxt_id." The rule implementing this chec

Re: random(3) in OpenBSD

Hi Bruno, On Nov 14 19:33, Bruno Haible wrote: > [CCing bug-gnulib] > > Hi Corinna, > > > Looking into all the BSD variants of random(), I found that OpenBSD > > defaults the random() function to return non-deterministic output. It > > works like this: > > > > - A global var random_determinis

Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)

Sam James wrote: > > It appears that the obstack gnulib module is the culprit. I replied: > Therefore, if it is a bug in gnulib, it is also a bug in glibc. Sam was right. I was wrong. It is a bug in the 'obstack' gnulib module. The scope - It is visible on CPUs that are - big-endian

Re: Patch: Fix OS X PowerPC support

On 14/11/2023 18:42, Bruno Haible wrote: I can't find the time to think through the detailed results that you listed. I hope you can do that. No worries, hopefully I wont end up being to much of a bother. But in summary, my point was "the patch is odd, because it uses MIN in one place and MAX

Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)

Hi Jeffrey, > On SPARC, 64-bit words can be loaded and saved through one of two > instructions. The first version is optimized, the second version is > not. The optimized version is faster, but the 64-bit words have to be > aligned to 8-byte boundaries. I.e., naturally aligned. > > If you are per

Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)

On 2023-11-13 21:50, Jeffrey Walton wrote: [1] also says: "By default, this boundary is aligned so that the object can hold any type of data." Needs to be investigated in more depth... ... When using the default toolchain settings, -xmemalign=8s is used, which causes the toolchain to use the op

Re: Patch: Fix OS X PowerPC support

Sevan Janiyan wrote: > On 10/11/2023 02:41, Sevan Janiyan wrote: > > On 09/11/2023 23:48, Bruno Haible wrote: > >> The patch tests MAC_OS_X_VERSION_MIN_REQUIRED in one place and > >> MAC_OS_X_VERSION_MAX_ALLOWED in the other place. What if someone compiles > >> for a range that includes both 10.4 a

Re: random(3) in OpenBSD

[CCing bug-gnulib] Hi Corinna, > Looking into all the BSD variants of random(), I found that OpenBSD > defaults the random() function to return non-deterministic output. It > works like this: > > - A global var random_deterministic defaults to 0. > - Calls to srandom() set random_deterministic

Re: new module 'rand'

On 2023-11-09 I wrote: > Could it be that rand() is not multithread-safe? > > According to the standards, rand() should be multithread-safe. Nope, I was mistaken there. See [1] for the details. So, the crash on CHERI was due to buggy code in the gnulib tests, meanwhile fixed through [2]. Thus,

Re: test-fenv-* failures on legacy Darwin/powerpc

On 11/11/2023 09:56, Bruno Haible wrote: There is even a complete example in the book PowerPC Numerics pages 96..99 Thanks for the link, I'll give it a try. :) Sevan

Re: Patch: Fix OS X PowerPC support

On 10/11/2023 02:41, Sevan Janiyan wrote: On 09/11/2023 23:48, Bruno Haible wrote: The patch tests MAC_OS_X_VERSION_MIN_REQUIRED in one place and MAC_OS_X_VERSION_MAX_ALLOWED in the other place. What if someone compiles for a range that includes both 10.4 and 10.5? That is,    MAC_OS_X_VERSION_M

Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)

On Tue, Nov 14, 2023 at 5:13 AM John Paul Adrian Glaubitz wrote: > > Hi Jeffrey! > > On Tue, 2023-11-14 at 00:50 -0500, Jeffrey Walton wrote: > > On SPARC, 64-bit words can be loaded and saved through one of two > > instructions. The first version is optimized, the second version is > > not. The o

Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)

Hi Jeffrey! On Tue, 2023-11-14 at 00:50 -0500, Jeffrey Walton wrote: > On SPARC, 64-bit words can be loaded and saved through one of two > instructions. The first version is optimized, the second version is > not. The optimized version is faster, but the 64-bit words have to be > aligned to 8-byte

*printf-posix: Revert expectations of %lc of 0

On 2023-03-21 I noticed a bug with %lc in most libcs: . On 2023-03-28 Eric Blake opened a defect with POSIX, with the intent that both ISO C and POSIX make the four *printf cases consistent:

Re: test environments

Marc Nieper-Wißkirchen wrote: > I have acquired a Raspberry Pi with an ARMv8 Good point. I added a bit more info: https://git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=commitdiff;h=09212bac9fc0e41fe11826d9d89965d8e54d4c98 Bruno

Re: test environments

Hi Bruno, Thanks for making your module available. I have acquired a Raspberry Pi with an ARMv8, so as soon as my time permits, I should be able to do some testing. Marc Am Mo., 13. Nov. 2023 um 00:10 Uhr schrieb Bruno Haible : > Marc Nieper-Wißkirchen wrote: > > I only have access to x86_64 s