On Tue, Nov 14, 2023 at 12:50 AM Jeffrey Walton wrote:
>
> On Mon, Nov 13, 2023 at 10:37 PM Bruno Haible wrote:
> >
> > Sam James wrote:
> > > It appears that the obstack gnulib module is the culprit.
> >
> > When I compile texinfo-7.1 in such a way that is uses the obstack facility
> > from
On Mon, Nov 13, 2023 at 10:37 PM Bruno Haible wrote:
>
> Sam James wrote:
> > It appears that the obstack gnulib module is the culprit.
>
> When I compile texinfo-7.1 in such a way that is uses the obstack facility
> from glibc (via 'gl_cv_func_obstack=yes ../configure ...'), I see the same
> bus
Sam James wrote:
> It appears that the obstack gnulib module is the culprit.
When I compile texinfo-7.1 in such a way that is uses the obstack facility
from glibc (via 'gl_cv_func_obstack=yes ../configure ...'), I see the same
bus error as in a build where the obstack facility comes from gnulib.
A partial answer to the question why Gnulib has no replacement.
2023-11-13 Bruno Haible
doc: Add a note.
* doc/posix-headers/stdatomic.texi: Add a note about the memory model.
diff --git a/doc/posix-headers/stdatomic.texi b/doc/posix-headers/stdatomic.texi
index
Gavin Smith writes:
> On Sun, Nov 12, 2023 at 12:41:58PM +0100, John Paul Adrian Glaubitz wrote:
>
>> > diff tree.c.old tree.c -u
>> > --- tree.c.old 2023-11-04 16:15:13.632755680 +
>> > +++ tree.c 2023-11-04 16:16:36.211072521 +
>> > @@ -43,7 +43,10 @@
>> >if
Hi,
On Sat, 11 Nov 2023, Bruno Haible wrote:
> 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()`
On Sat, Nov 11, 2023 at 11:54:52PM +0100, Bruno Haible wrote:
>
> These types are all identical. Therefore you don't even need to cast.
>
> - char32_t comes from (ISO C 11 or newer).
> - ucs4_t comes from GNU libunistring.
> - uint32_t comes from .
According to your mail
Jessica Clarke wrote:
> So it’s not really a case of not being necessary, it’s a case of “are
> you using void * or using void * __capability everywhere to opt into
> capability use?”
Indeed, when I try to compile the current Gnulib code in "hybrid" mode
(CC="clang -march=morello"), I get
> * m4/valgrind-helper.m4: New file.
Oops, that file was incomplete. Fixed like this:
2023-11-13 Bruno Haible
jit/cache: Fix configure test.
* m4/valgrind-helper.m4 (gl_VALGRIND_HELPER): Check already at configure
time whether exists. Fix AC_DEFINE_UNQUOTED
On 2023-11-12 20:15, Jessica Clarke wrote:
it’s a case of “are
you using void * or using void * __capability everywhere to opt into
capability use?” Unless that’s what you mean by necessary?
It seems pretty clear that Gnulib should run, run away from hybrid mode
as fast as it can.
On 2023-11-12 19:10, Bruno Haible wrote:
So, if I understood it correctly, in hybrid mode (2), programs (especially
memory allocators)_can_ use and its functions, but it's not
necessary since the programs will also work without it?
So __CHERI__ currently means "either hybrid or pure
11 matches
Mail list logo
