After each glibc release, we should update the Gnulib documentation accordingly.
This patch does it for the glibc 2.33 release (a month ago).
2021-03-06 Bruno Haible
free-posix: Update documentation.
* doc/posix-functions/free.texi: Add platform details.
2021-03-06 Bruno Hai
On 3/2/21 7:25 PM, Bruno Haible wrote:
$ ./gnulib-tool --create-testdir --dir=../testdir-all --single-configure
gnulib-tool: warning: module parse-datetime2 depends on a module with an
incompatible license: gettime
...
Thanks for the heads-up; I had forgotten about the parse-datetime
special
On 3/2/21 7:27 PM, Bruno Haible wrote:
a general macro won't cut it e.g. for coreutils. coreutils
has multithreaded programs ('sort') next to single-threaded programs.
But coreutils wants to optimize wcwidth. GNULIB_WCHAR_SINGLE actually
means "assume that the locale has been set before the prog
On 2/21/21 10:41 AM, Bruno Haible wrote:
it seems that some functions have a 'gl_' prefix and some
don't. Does this matter? Maybe it does not matter because
the contents of lib/malloc/dynarray.h is irrelevant and only
lib/malloc/dynarray-skeleton.c matters?
The idea was that the gl_* symbols wo
On 1/14/21 2:00 AM, Florian Weimer wrote:
We saw commercial demand for Shift-JIS much later than that.
Yes, I see Red Hat has a product enhancement for that, for coreutils,
dated 2019.[1]
Shift-JIS is still very much alive and kicking in Japan in its own
circles. Even DBCS EBCDIC is still u
Paul Eggert wrote:
> Thanks for the heads-up; I had forgotten about the parse-datetime
> special case for licensing. I installed the attached 1-byte patch to
> work around the issue.
Thanks. I had forgotten about this special case as well...
Bruno
Paul Eggert wrote:
> However, my worry is that good support for non-ASCII-safe encodings like
> Shift-JIS is hard to do, and that any such support we'd add to
> Gnulib/coreutils/etc. would not only increase maintenance costs and
> reduce runtime performance
Shift_JIS is not the only non-ASCII-s
Paul Eggert wrote:
> The idea was that the gl_* symbols would not compete with the like-named
> __libc_* symbols when Gnulib dynarray is built under glibc. I don't
> recall the details about the competition, unfortunately.
Ah, it's to avoid conflicts with glibc. I thought it was pure convenience
Paul Eggert wrote:
> Perhaps it'd work without the "#define __libc_dynarray_resize
> gl_dynarray_resize" etc. lines, because the two sets of
> __libc_*dynarray* functions would be in different C namespaces? But it
> might be confusing to debug.
No, there would be conflicts with glibc. In C, the
