Collin Funk wrote:
> I've committed the attached patch.
Looks good. Thanks.
Bruno
* modules/getusershell-tests: New file.
* tests/test-getusershell.c: New file.
---
ChangeLog | 6 +++
modules/getusershell-tests | 12 +
tests/test-getusershell.c | 96 ++
3 files changed, 114 insertions(+)
create mode 100644 modules/getu
Hi Pádraig,
On 5/13/24 2:32 PM, Pádraig Brady wrote:
> I've an 18 year old script template here that silences Ctrl-C spew:
> https://www.pixelbeat.org/talks/python/cli_skel.py
Ah, okay I think I understand this now. So basically the backtrace is
the default excepthook and your code skips running
Thanks.
I'm adding a signature test. (So far, we have a signature test for these
functions only in C++ mode, in tests/test-unistd-c++.cc.)
2024-05-15 Bruno Haible
getusershell tests: Verify the function declarations.
* tests/test-getusershell.c: Include signature.h.
(
Hi Bruno,
On 5/15/24 3:06 AM, Bruno Haible wrote:
> I'm adding a signature test. (So far, we have a signature test for these
> functions only in C++ mode, in tests/test-unistd-c++.cc.)
Thanks! I would have added them if I saw them there.
Should all glibc functions have a signature check? For the
Hi Collin,
> Should all glibc functions have a signature check? For these ones I
> was conflicted on adding them since they are not standardized, but
> provided on BSD and glibc.
If Gnulib is not the only implementation, then yes it is advisable
to have the signature check.
For example, if on so
Hello,
We’ve seen a compiler warning in the vasnprintf module (as copied into
GLib) when building with GCC 14 (on msys2, although I don’t think
that’s relevant).
```
../glib/gnulib/vasnprintf.c: In function 'multiply':
../glib/gnulib/vasnprintf.c:382:21: error: allocation of insufficient
size '1'
Hi,
Philip Withnall wrote:
> We’ve seen a compiler warning in the vasnprintf module (as copied into
> GLib) when building with GCC 14 (on msys2, although I don’t think
> that’s relevant).
>
> ```
> ../glib/gnulib/vasnprintf.c: In function 'multiply':
> ../glib/gnulib/vasnprintf.c:382:21: error: a
Hi,
On Wed, 2024-05-15 at 17:14 +0200, Bruno Haible wrote:
> > The fix we’ve put together for GLib is here, and makes the obvious
> > switch from allocating one byte to allocating `sizeof (mp_limb_t)`:
> > https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4066/diffs?commit_id=cbc58085455b699e9c
On 2024-05-13 15:34, Collin Funk wrote:
To fix this, please use _GL_INLINE and implement with inline functions. And add
please add test cases to catch these issues.
If we can ensure byteswap.h functions are defined as functions,
wouldn't it make sense to just define these as macros to them?
N
* lib/stdbit.in.h (stdc_first_leading_zero)
(stdc_first_leading_one, stdc_first_trailing_zero_uc)
(stdc_first_trailing_one_uc): Redo to avoid the need for a
conditional branch, at least on x86-64 with GCC 14.
---
ChangeLog | 7 +-
lib/stdbit.in.h | 60 ---
* lib/stdbit.in.h (__gl_stdbit_clz, __gl_stdbit_clzl)
(__gl_stdbit_clzll, __gl_stdbit_ctz, __gl_stdbit_ctzl)
(__gl_stdbit_ctzll): Work even if the argument is zero.
All callers changed. This should help avoid branches
on non-GCC-like platforms.
---
ChangeLog | 9 ++
lib/stdbit.in.h | 7
The module 'stdbit' defines 70 functions, grouped into 14 function-like
macros. Most packages will only need 1 or 2 among these 14 function groups.
(For example, diffutils needs only 'stdc_bit_width'.)
The amount of code generated by the stdbit module is not negligible:
With gcc -O0:
$ size g
Hi Bruno,
On 5/15/24 4:06 PM, Bruno Haible wrote:
> The module 'stdbit' defines 70 functions, grouped into 14 function-like
> macros. Most packages will only need 1 or 2 among these 14 function groups.
> (For example, diffutils needs only 'stdc_bit_width'.)
Maybe it makes sense to provided a modu
Like for the other *.in.h files, it makes sense to add a unit test
for this .h file. Done through the second patch below.
It uncovers a compilation error:
g++ -ftrapv -DHAVE_CONFIG_H -I. -I../../gltests -I..
-DGNULIB_STRICT_CHECKING=1 -DIN_GNULIB_TESTS=1 -I. -I../../gltests -I..
-I../../gltest
On 5/15/24 12:03 PM, Paul Eggert wrote:
>> If we can ensure byteswap.h functions are defined as functions,
>> wouldn't it make sense to just define these as macros to them?
>
> Not sure why macros would be helpful. If functions suffice for good
> performance when compiling with -O2, it's better t
Collin Funk wrote:
> Maybe it makes sense to provided a module covering all the stdbit.h
> functions?
Yes. That's why I wrote:
We thus have the following modules:
- stdbit-h for just the header file,
- stdc_* for the 14 function groups,
- stdbit for all together. <
Hi Pádraig,
On 5/13/24 2:32 PM, Pádraig Brady wrote:
> https://github.com/pixelb/crudini/blob/cbb3b85e/crudini.py#L1134
> Note that also handles a closed stdin (and stdout elsewhere in that util).
I just pushed the attached patch following your code there. Works well
for me. Thanks for the help.
Hi Collin,
> $ gnulib-tool --create-testdir --dir testdir1
> ^C
> $
It does not print any diagnostic. While gnulib-tool.sh and
subprocesses do print a diagnostic:
$ rm -rf ../testdir1; ./gnulib-tool.sh --create-testdir --dir=../testdir1
--single-configure stdbit-h
Module list with i
On 5/15/24 8:45 PM, Bruno Haible wrote:
> Can you make gnulib-tool.py print a diagnostic in this case as well?
> It does not need to be exactly "caught signal SIGINT", like bash does.
> Just an indication that
> - gnulib-tool.py
> - is being terminated
> - due to a signal 2.
> Preferrably for
20 matches
Mail list logo
