Re: c32width gives incorrect return values in C locale

> From: Bruno Haible > Cc: bug-libunistr...@gnu.org > Date: Sat, 11 Nov 2023 23:54:52 +0100 > > [CCing bug-libunistring] > Gavin Smith wrote: > > I did not understand why uc_width was said to be "locale dependent": > > > > "These functions are locale dependent." > > > > - from > >

Re: *alloc: Take advantage of CHERI bounds-checking

I wrote: > Now I'd like to try CHERI on packages like gettext, and see whether > it finds bugs that neither valgrind nor the gcc bounds-checking options > can detect. Did that. Indeed, CHERI found a memory overrun bug that valgrind had not found [1]. Just by running "make check" after configuring

Re: *alloc: Take advantage of CHERI bounds-checking

> This set of patches handles most memory allocators that we have in gnulib. And this patch handles the 'ssfmalloc' memory allocator. 2023-11-11 Bruno Haible ssfmalloc: Take advantage of CHERI bounds-checking. * lib/ssfmalloc.h: Include . (struct

Re: c32width gives incorrect return values in C locale

[CCing bug-libunistring] Gavin Smith wrote: > I did not understand why uc_width was said to be "locale dependent": > > "These functions are locale dependent." > > - from > . That's because some

Re: [PATCH] printf_parse: fix off-by-two

Johannes Schindelin wrote: > In 480a59ba60 (*printf-posix: ISO C 23: Support size specifiers 'wN' and > 'wfN'., 2023-03-24), a major refactoring hides a bug in the conversion > of the code handling Windows' `%I64*` family of `printf()` formats: > before the refactoring, the `64` part was skipped

Re: c32width gives incorrect return values in C locale

On Sat, Nov 11, 2023 at 09:06:41PM +0100, Bruno Haible wrote: > [CCing bug-gnulib] > Indeed, the c32* functions by design work only on those Unicode characters > that can be represented as multibyte sequences in the current locale. > > I'll document this better in the Gnulib manual. > > Since

Re: hooks for memory allocators

Bruno Haible writes: > Sam James wrote: >> I don't think this applies to gnulib, but it feels relevant enough for >> me to mention it: for packages with their own allocator where they >> retain a pool, it may be worth adding ASAN attributes/hooks. >> >> Emacs did this a little while ago in >>

[PATCH] printf_parse: fix off-by-two

In 480a59ba60 (*printf-posix: ISO C 23: Support size specifiers 'wN' and 'wfN'., 2023-03-24), a major refactoring hides a bug in the conversion of the code handling Windows' `%I64*` family of `printf()` formats: before the refactoring, the `64` part was skipped (as desired), but afterwards that

Re: *alloc: Take advantage of CHERI bounds-checking

On 2023-11-11 13:23, Bruno Haible wrote: Ah? Which documented functions should I be wary of? Not sure. But for starters, vaddr_t is obsolete. I was toying with the idea of not using cheri.h, and just using compiler builtins. That may be going too far, though.

Re: hooks for memory allocators

Sam James wrote: > I don't think this applies to gnulib, but it feels relevant enough for > me to mention it: for packages with their own allocator where they > retain a pool, it may be worth adding ASAN attributes/hooks. > > Emacs did this a little while ago in >

Re: *alloc: Take advantage of CHERI bounds-checking

Paul Eggert wrote: > I tried hard to add support with as few #ifdefs as possible, to avoid > cluttering the code. Instead, I created a relatively small include file > ptr-bounds.h that packaged things up into easy-to-use macros. This meant > most of the rest of the Emacs code didn't need to use

Re: *alloc: Take advantage of CHERI bounds-checking

Bruno Haible writes: > I was impressed by the fact that CHERI detected the multithread-safety > bug of gnulib's use of rand() in the test suite. > > Now I'd like to try CHERI on packages like gettext, and see whether > it finds bugs that neither valgrind nor the gcc bounds-checking options >

Re: *alloc: Take advantage of CHERI bounds-checking

On 2023-11-11 11:14, Bruno Haible wrote: I was impressed by the fact that CHERI detected the multithread-safety bug of gnulib's use of rand() in the test suite. I was also impressed in 2017 when Intel MPX found some pointer bugs in Emacs, and I added support to Emacs for gcc

*alloc: Take advantage of CHERI bounds-checking

I was impressed by the fact that CHERI detected the multithread-safety bug of gnulib's use of rand() in the test suite. Now I'd like to try CHERI on packages like gettext, and see whether it finds bugs that neither valgrind nor the gcc bounds-checking options can detect. For this purpose, it is

Re: [PATCH 2/2] rawmemchr: port better to CHERI

Paul Eggert wrote: > * lib/rawmemchr.c (rawmemchr): Use unsigned char for longword, > since CHERI doesn’t allow the aligned-word trick to speed up > performance. The rawmemchr unit test passed for me, on CHERI. This means we are lacking a unit test for this situation. I'm adding one: 2023-11-11

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

I wrote: > Just found that xnu/osfmk/ppc/status.c contains a function > thread_enable_fpe(), and this function gets called from > xnu/bsd/kern/kern_sig.c when a SIGFPE signal handler is installed > (value != SIG_DFL or SIG_IGN). > > Can you try to install this handler for SIGFPE? > > static void

Re: doc: Mention rand and srand limitations

Jeffrey Walton wrote: > > The attached program tests the MT-safety. Results: OK on all platforms, > > except > > ... > > If rand() and friends do not need to be MT-safe, then does it even need a > test? I wrote the test (but did not commit it into gnulib) because rand() is MT-safe on GNU. If I

Re: [PATCH 1/2] di-set: port better to CHERI-64

Paul Eggert wrote: > (hashint): Make it uintptr_t, not size_t, since it’s for use > when converting to pointer and back again. This suppresses > a false positive on CHERI-64. Nice! I looked into this one just yesterday, but did not know how to deal with it. Bruno

[PATCH 2/2] rawmemchr: port better to CHERI

* lib/rawmemchr.c (rawmemchr): Use unsigned char for longword, since CHERI doesn’t allow the aligned-word trick to speed up performance. --- ChangeLog | 7 +++ lib/rawmemchr.c | 13 + 2 files changed, 16 insertions(+), 4 deletions(-) diff --git a/ChangeLog b/ChangeLog

[PATCH 1/2] di-set: port better to CHERI-64

* lib/di-set.c: Include stdint.h. (hashint): Make it uintptr_t, not size_t, since it’s for use when converting to pointer and back again. This suppresses a false positive on CHERI-64. * modules/di-set (Depends-on): Add stdint. --- ChangeLog | 7 +++ lib/di-set.c | 3 ++-