Bruno Haible via Gnulib discussion list writes:
> Therefore we can remove or alias 'realloc-gnu'. In order to avoid possible
> complaints, I'm making it a module alias for 'realloc-posix'.
Thanks. I applied this minor correction. I see you copied the
deprecation notice from 'dosname' but forgot
Paul Eggert wrote:
> > If we let realloc-gnu and realloc-0safe exist both in Gnulib, we need to add
> > a conflict-detection mechanism in gnulib-tool.
>
> Ah, in that case you're right, let's just remove realloc-gnu.
I notified the inetutils and liblouis people:
https://lists.gnu.org/archive/html
On 2024-10-27 13:39, Bruno Haible wrote:
The correct pattern to use is the one introduced by
https://lists.gnu.org/archive/html/bug-gnulib/2022-01/msg00020.html .
Thanks, I'll look at that pattern for the new module.
Thanks - I am happy with this version, or even without the user-visible logic too (not sure if this is something users should ever tune). My question about selection logic was more for maintainers rather than end-users./Simon27 okt. 2024 kl. 23:04 skrev Sam Russell :I had a play with autoconf (ins
I had a play with autoconf (inspired heavily by m4/debug.m4), can confirm
the behaviour works as follows:
# build with slice-by-8 (default enabled)
./configure
make
gltests/bench-crc 100
real 1.714850
user 1.715
sys0.000
# build without slice-by-8
./configure --disable-crc-slice-by-8
m
Paul Eggert wrote:
> > https://www.gnu.org/software/gnulib/manual/html_node/Modules-that-modify-the-way-other-modules-work.html
> >
> > How would you answer the question
> >“If my module occurs among the modules of gltests, should it
> > have an effect on the modules in gllib?”
> > in this
On 2024-10-27 11:53, Bruno Haible wrote:
https://www.gnu.org/software/gnulib/manual/html_node/Modules-that-modify-the-way-other-modules-work.html
How would you answer the question
“If my module occurs among the modules of gltests, should it
have an effect on the modules in gllib?”
in thi
Paul Eggert wrote:
> It should be better for OpenBSD 6.2+ when doing cross-builds, because it
> guesses that the bug is fixed there.
Oh, I see: the main part was the change of the cross-compilation guess,
and the part with sizeof (void *) is meant as a no-op.
I was confused by the part with size
On 2024-10-27 11:43, Bruno Haible wrote:
If we let realloc-gnu and realloc-0safe exist both in Gnulib, we need to add
a conflict-detection mechanism in gnulib-tool.
Ah, in that case you're right, let's just remove realloc-gnu.
Paul Eggert wrote:
> > For the others, I would say that '*-0safe' variants are not needed, because
> > the allocation is special and therefore the programmer can be assumed to be
> > careful there (cf. option (c) in [1]).
>
> I'd rather not make that assumption, as programmers are too error-prone
Paul Eggert wrote:
> Agreed, though, that realloc-gnu should be made obsolescent or removed
> or whatever.
OK, good to hear.
> > Hmm. This module would semantically conflict with 'realloc-gnu', no?
> > Because 'realloc-gnu' mandates that realloc(p,0) behaves in one way,
> > and 'realloc-0safe' m
On 2024-10-27 09:51, Bruno Haible wrote:
Paul Eggert wrote:
How about 'alloc-0-nonnull'?
Whatever the module's name is, it should affect malloc too, as there's
little point to adjusting realloc without also adjusting malloc.
A dependency from the new module to 'malloc-gnu' should fit the bill,
On 2024-10-27 10:08, Bruno Haible wrote:
Hmm. This module would semantically conflict with 'realloc-gnu', no?
Because 'realloc-gnu' mandates that realloc(p,0) behaves in one way,
and 'realloc-0safe' mandates that it behaves in another way.
I think we need to remove the 'realloc-gnu' module first
On 2024-10-27 10:13, Bruno Haible wrote:
I don't understand this ChangeLog entry. If it is fixed in OpenBSD >= 6.2,
it's a "port better to OpenBSD <= 6.1", no?
It should be better for OpenBSD 6.2+ when doing cross-builds, because it
guesses that the bug is fixed there.
It shouldn't affect Op
> > > How could we call this module? 'realloc-ee' sounds too synthetic.
> >
> > How about 'alloc-0-nonnull'?
> >
> > Whatever the module's name is, it should affect malloc too, as there's
> > little point to adjusting realloc without also adjusting malloc.
>
> A dependency from the new mod
Paul Eggert wrote:
> + posix_memalign: port better to OpenBSD 6.2+ cross
> + * m4/posix_memalign.m4 (gl_FUNC_POSIX_MEMALIGN):
> + Don’t assume sizeof (void *) <= 32 (!).
> + The bug is fixed in OpenBSD 6.2+.
I don't understand this ChangeLog entry. If it is fixed in OpenBSD >= 6.2,
Paul Eggert wrote:
> Even if we remove eealloc we might as well add commentary
> explaining some of its confusion, before we remove it.
Thanks for these changes. Although, as indicated in [1], I think
we should promote this module. At least until we have a rock-solid
replacement with the original
Paul Eggert wrote:
> (We have too
> many memory allocation modules and a cleanup is needed, but that's a
> different topic)
It's easy to get this feeling. But the fix, IMO, is to give an overview
of the modules in the documentation, and how they differ.
> > How could we call this modul
It is hard to learn about the existing Gnulib modules.
Even I had forgotten about the 'eealloc' and 'safe-alloc' modules
over the years. And when starting to use module 'string-buffer'
in xgettext, it took me something like 15 minutes to find this
module.
The texinfo-formatted documentation covers
Simon Josefsson wrote:
> I am not certain about the method to enable/disable the optimization,
> is the configure.ac variable the best method we have?
An AC_ARG_ENABLE invocation can be added. Since Sam said that he's not familiar
with Autoconf, it would be your turn to add it...
Bruno
Looks good to me too - although I am not certain about the method to
enable/disable the optimization, is the configure.ac variable the best method
we have?
/Simon
> 27 okt. 2024 kl. 14:20 skrev Bruno Haible :
>
> Looks good to me now.
>
> Simon?
>
>
>
Looks good to me now.
Simon?
thanks, moved the xors to the front of the lines
On Sun, Oct 27, 2024, 13:41 Bruno Haible wrote:
> Sam Russell wrote:
> > > Also, in GNU coding style, when line breaking is needed within
> > expressions,
> > > we do the line break before the operator, not after the operator. [1]
> > > This affec
Sam Russell wrote:
> > Also, in GNU coding style, when line breaking is needed within
> expressions,
> > we do the line break before the operator, not after the operator. [1]
> > This affects lib/crc.c lines 73..80, 102..103.
>
> Done.
I meant this expression:
crc = crc32_sliceby8_table[0][(lo
> Unfortunately, 'indent' introduced tabs. In Gnulib, we indent with spaces,
> not tabs (except in Makefiles and ChangeLog). Can you please untabify:
Done.
> Also, in GNU coding style, when line breaking is needed within
expressions,
> we do the line break before the operator, not after the opera
Addendum to:
> Unfortunately, 'indent' introduced tabs. In Gnulib, we indent with spaces,
> not tabs (except in Makefiles and ChangeLog).
We have some documentation about this:
https://www.gnu.org/software/gnulib/manual/html_node/Indent-with-spaces-not-TABs.html
Bruno
Sam Russell wrote:
> I used Simon's indent trick on both files
Unfortunately, 'indent' introduced tabs. In Gnulib, we indent with spaces,
not tabs (except in Makefiles and ChangeLog). Can you please untabify:
$ expand < lib/crc.c > lib/crc.cx && mv lib/crc.clib/crc.c
$ expand < lib/crc-generat
> You can fix most of these by simply running 'indent' on your *.h and *.c
Thanks, this is super helpful. I'm happy to follow the coding style but a
linter would make it easier for me to track down these whitespace issues.
> Regarding the Automake stuff, please try the attached patch, on top of
y
Thanks Sam, I think we are closing in on a good patch, and Bruno's
feedback seems good. Just one small piece of hint:
Bruno Haible via Gnulib discussion list writes:
> 3) Use GNU coding style:
You can fix most of these by simply running 'indent' on your *.h and *.c
files, and then manually rev
29 matches
Mail list logo
