[PATCH 2/2] stdbit: port to theoretical platforms

Port to theoretical platforms that C and POSIX allow but are not likely to ever exist. This is mostly just to document the existing source code: when optimizing, the machine code should be largely unchanged even on platforms lacking __builtin_clz etc. * lib/stdbit.in.h: Omit static_assert that che

[PATCH 1/2] stdbit-tests: make GNULIB_TEST_STDBIT work standalone

* modules/stdbit-tests (GNULIB_TEST_STDBIT): Do not define in config.h, since config.h is conditionally included depending on this macro. Instead, specify -DGNULIB_TEST_STDBIT in the CPPFLAGS of each test. --- ChangeLog| 9 + modules/stdbit-tests | 18 -- 2 fil

endian: New module.

I haven't pushed this since it is my first time attempting the gnulib header wizardry and doing anything of value in Autoconf. The configure check should check for unique values of LITTLE_ENDIAN and BIG_ENDIAN, and that BYTE_ORDER is defined to one of them. POSIX doesn't require PDP_ENDIAN and I w

Re: endian: New module.

Hi Collin, > Let me know if I missed anything. Other than the docs and test module > which I can do later today (assuming this patch is decent enough). The doc changes belong in the same commit. The tests module should be in a different commit, but it's a good idea to develop both together, since

Re: execinfo: Add tests.

Hi Collin, In the ChangeLog entry: + * tests/test-execinfo.c (test_backtrace): New function. Simply test that + the symbols defined in execinfo.h can be used. + (main): Use it. For a new file that is not based on another file, it's sufficient to say "New file." No need to go in

doc: Document function-like macros

This patch lists the 14 function-like macros from in the documentation. I'm not documenting the 70 functions (with suffixes _uc, _us, _ui, _ul, _ull), because this would be excessive (for my taste). It also updates the platforms list for : macOS and Cygwin were missing from the list where the he

Re: considering L1 cache

Hi Paul, > substituting something > more straightforward than a de Bruijn hash (possibly faster?). > ... > +#if !defined _GL_STDBIT_HAS_BUILTIN_CLZ && !_MSC_VER > +/* __gl_stdbit_clztab[B] is the number of leading zeros in > + the 8-bit byte with value B. */ > +char const __gl_stdbit_clztab[256

Re: doc: Document function-like macros

Thanks for doing that. A later free draft of C23 is available, so I installed the attached. I think the section numbers are the same (though I didn't check this).From 623b86c05be45e5e567b828cd71d1b78c52012db Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 13 May 2024 09:29:00 -0700 Subject

gnulib-tool Python tracebacks after control-C

I realized that I invoked ' ./gnulib-tool --create-testdir --dir foo stdbit' with the wrong options so I interrupted it with control-C. It then gave me the following long traceback, which is not useful. I suggest shutting off the Python traceback info after control-C unless perhaps some new deb

[PATCH] stdbit: fix typo in MS-Windows port

Problem reported by Mattias Engdegård . * lib/stdbit.in.h (__gl_stdbit_popcount_support) [_MSC_VER]: Fix misspelling in decl. --- ChangeLog | 7 +++ lib/stdbit.in.h | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog i

Re: *.m4 conventions

Paul Eggert wrote: > Is this stuff documented somewhere in the .texi files? If not, I suppose > it should be. Done through the patch below. > Frankly I continue to be annoyed by having to read and write a line "# > FILENAME.m4" at the start of every m4 file FILENAME.m4. It's better for > a fil

Re: Python class comments

Collin Funk wrote: > # > # Define GLImport class > # > class GLImport: > > > But when searching for a class in Python you can simply look up > '^class NAME:' since whitespace matters in that language. No need for > the comment in my opinio

Re: doc: Document function-like macros

Paul Eggert wrote: > A later free draft of C23 is available, so I installed the attached. Thanks. > I think the section numbers are the same (though I didn't check this). No need to check: I was perusing the n3096.pdf when looking up the sections. But I had not noticed that the reference in the

why __gl_ prefix?

Hi Paul, In the stdbit and binary-io modules, you have been introducing a number of a symbols with prefix __gl_. I would propose to remove the first underscore, that is, to rename them to _gl_*. Rationale: * It is well understood that symbols prefixed with __ belong to the implementation of th

Re: endian: New module.

Unfortunately this patch suffers from the problem we discussed earlier, e.g., the substitute be16toh (n++) has undefined behavior but it should add 1 to n and otherwise act as if be16toh (n) was called. Also, the returned values and types are sometimes wrong. E.g., on x86-64 be16toh (-1) shoul

Re: [PATCH 2/4] stdbit-tests: new module

Hi Paul, > * tests/tst-stdc_trailing_zeros.c: > New files, copied verbatim from glibc. The file name prefix 'tst-' bothers me a bit, because * It is inconsistent with the prefix 'test-' that we've been using since 2003. * It causes more typing, because the autocompletion t → test n

Re: why __gl_ prefix?

On 2024-05-13 10:33, Bruno Haible wrote: In the stdbit and binary-io modules, you have been introducing a number of a symbols with prefix __gl_. I would propose to remove the first underscore, that is, to rename them to_gl_*. Rationale: * It is well understood that symbols prefixed with __ belo

Re: [PATCH 2/4] stdbit-tests: new module

On 2024-05-13 10:47, Bruno Haible wrote: I would propose to rename the files to 'test-*' in Gnulib. They are not likely to be modified frequently in glibc, therefore the gnulib <--> glibc merge effort is likely zero. And annotate the mapping in config/srclist.txt accordingly. Wouldn't we also

Re: *.m4 conventions

On 2024-05-13 09:57, Bruno Haible wrote: Note that in Gnulib, a human-readable comment # Autoconf macros for the stdio module. is just as trivial as this comment: # stdio_h.m4 Although that's true for experts, it's not necessarily true for beginners who are the main audience for the firs

Re: *.m4 conventions

Paul Eggert wrote: > Although that's true for experts, it's not necessarily true for > beginners who are the main audience for the first line. A beginner won't > know whether stdio_h.m4 is for the entire stdio module, or just for > configuring the stdio.h replacement, or just for configuring the

Re: endian: New module.

Hi Bruno, On 5/13/24 5:38 AM, Bruno Haible wrote: >> Let me know if I missed anything. Other than the docs and test module >> which I can do later today (assuming this patch is decent enough). > > The doc changes belong in the same commit. The tests module should be > in a different commit, but i

Re: execinfo: Add tests.

On 5/13/24 8:12 AM, Bruno Haible wrote: > For a new file that is not based on another file, it's sufficient to say > "New file." No need to go into the details of what the file contains. > The reason is that the purpose of a ChangeLog is "so that people investigating > bugs in the future will know

Re: gnulib-tool Python tracebacks after control-C

Hi Paul, On 5/13/24 9:39 AM, Paul Eggert wrote: > I realized that I invoked ' ./gnulib-tool --create-testdir --dir foo stdbit' > with the wrong options so I interrupted it with control-C. It then gave me > the following long traceback, which is not useful. I suggest shutting off the > Python tr

Re: Python class comments

On 5/13/24 10:10 AM, Bruno Haible wrote: > I find these comments useful, in particular in files that contains > several classes, such as GLFileSystem.py. > > This is because I apparently work differently from you: When I open > a source code file: > - I do so in a window with at least 50 lines,

Re: [PATCH 3/4] stdbit: remove most module dependence

Hi Paul, On 5/11/24 12:08 PM, Paul Eggert wrote: > diff --git a/modules/stdbit b/modules/stdbit > index 6096869774..f70386566b 100644 > --- a/modules/stdbit > +++ b/modules/stdbit > @@ -7,9 +7,6 @@ lib/stdbit.in.h > m4/stdbit_h.m4 > > Depends-on: > -count-leading-zeros [$GL_GENERATE_STDBIT_H]

Re: [PATCH 2/4] stdbit-tests: new module

Paul Eggert wrote: > > I would propose to rename the files to 'test-*' in Gnulib. They are > > not likely to be modified frequently in glibc, therefore the gnulib <--> > > glibc > > merge effort is likely zero. And annotate the mapping in config/srclist.txt > > accordingly. > > Wouldn't we also n

Re: gnulib-tool Python tracebacks after control-C

On 13/05/2024 21:48, Collin Funk wrote: Hi Paul, On 5/13/24 9:39 AM, Paul Eggert wrote: I realized that I invoked ' ./gnulib-tool --create-testdir --dir foo stdbit' with the wrong options so I interrupted it with control-C. It then gave me the following long traceback, which is not useful. I

Re: [PATCH 2/4] stdbit-tests: new module

Paul Eggert wrote: > > If you have objections to that, I would instead > >- move the tst-* files to a subdirectory, say from-glibc/, > >- change the module descriptions so that > >tests/from-glibc/tst-stdc_trailing_zeros.c > > is compiled to an executable named > >${tes

Re: endian: New module.

On 5/13/24 10:40 AM, Paul Eggert wrote: > Unfortunately this patch suffers from the problem we discussed earlier, e.g., > the substitute be16toh (n++) has undefined behavior but it should add 1 to n > and otherwise act as if be16toh (n) was called. [...] > These problems arise because Gnulib byte

Re: considering L1 cache

On 5/13/24 09:17, Bruno Haible wrote: The reason is that such a 256-bytes table will tend to occupy 256 bytes in the CPU's L1 cache, and thus reduce the ability of other code to use the L1 cache. Yes, it partly depends on whether the function is called a lot (so the 256-byte table is in the ca

Re: considering L1 cache

Paul Eggert wrote: > I installed the > attached. This probably a win (over de Bruijn too), at least for some > apps and platforms, though I haven't benchmarked. Thanks! Replacing a table access with ca. 7 arithmetic instructions definitely a win. I also love how this code makes use of condition

Re: considering L1 cache

You might be interested in this implementation: https://engineering.fb.com/2019/04/25/developer-tools/f14/ On Mon, May 13, 2024 at 4:24 PM Bruno Haible wrote: > > Paul Eggert wrote: > > I installed the > > attached. This probably a win (over de Bruijn too), at least for some > > apps and platform

Re: *.m4 conventions

On 2024-05-13 13:23, Bruno Haible wrote: # stdio_h.m4 - Autoconf macros for the stdio module. # serial 42 Oh, I didn't know you could do that. Thanks, I'll keep it in mind.

Python './gnulib-tool --create-testdir --dir F' should quickly warn if F exists

If I run this command twice, by mistake: ./gnulib-tool --create-testdir --dir foo -h stdbit ./gnulib-tool --create-testdir --dir foo -h stdbit The second invocation eventually fails with: ... executing automake --add-missing --copy patching file build-aux/test-driver /home/eggert/src/gn

Re: Python './gnulib-tool --create-testdir --dir F' should quickly warn if F exists

On 5/13/24 7:45 PM, Paul Eggert wrote: > I messed up. However, the shell implementation of gnulib-tool diagnoses my > mistake right away, before going on its slow way: > > $ GNULIB_TOOL_IMPL=sh ./gnulib-tool --create-testdir --dir foo -h stdbit > mkdir: cannot create directory ‘foo’: File exi

Re: Python './gnulib-tool --create-testdir --dir F' should quickly warn if F exists

Paul Eggert wrote: > Perhaps both implementations should quickly exit in this situation, come > to think of it. I agree. I've made the same mistake a number of times. There is no valid use for continuing if $destdir already exists, since the call is guaranteed to overwrite configure.ac, Makefile.

Re: Python './gnulib-tool --create-testdir --dir F' should quickly warn if F exists

Hi Bruno, On 5/13/24 8:47 PM, Bruno Haible wrote: >> Perhaps both implementations should quickly exit in this situation, come >> to think of it. > > I agree. I've made the same mistake a number of times. There is no valid use > for continuing if $destdir already exists, since the call is guarante