On mingw, the printf %f, %e, %g directives with a 'double' argument don't work right: For Inf and NaN, they produce results like "1.#INF00" or "1.#IND00". On top of that, they also omit the sign of -
Indeed. The support of UTF-16BE/LE in non-GNU iconv implementation is not good: - On Solaris >= 9, UTF-{16,32}{BE,LE} are fully supported. - On AIX 5.1, only UCS-2 is recognized, and it is actually U
It started as a test failure on Linux/SPARC64: test-logl.c:42: assertion failed FAIL: test-logl I tried to fix it by activating the gnulib replacement code for logl(). But the bug persisted. Debuggin
In the conversion from TCHAR_T[] to DCHAR_T[] in vasnprintf.c, there is an optimized loop for the case that the directive's result is entirely ASCII. There was a bug in this logic: On glibc systems,
Hi Bruno, Thanks for all of this work. I've taken the liberty of adding the above file. Without it, any use of gnulib with affected modules fails like this: gnulib/gnulib-tool: ** file /h/j/w/co/cu/g
When the handling of NaN and Inf is broken in the system's printf but the system's printf supports %a and %A, gnulib's replacement forgot to override the handling of NaN and Inf in this case. This fi
Going through the same process with clang: I started with most of the ca. 900 diagnostic options at https://releases.llvm.org/16.0.0/tools/clang/docs/DiagnosticsReference.html , omitting the redundan
This patch fixes a crash (abort) during the %s processing in vasnwprintf. vasnwprintf: Fix crash upon conversion failure when processing %s. * lib/vasnprintf.c (VASNPRINTF): When processing %s with !
Hi Bruno, That's what I was going to do, but the excerpt of `u16-conv-from-enc.c' that I quoted made me think that, e.g., "UTF-16BE" and "UTF-16LE" were only known to work on Glibc >= 2.2: /* Name of
Hi Paul, Three comments on this: * The code uses the snprintf() function but the module does not depend on the 'snprintf' or 'snprintf-posix' module. Do you intend to ignore these portability problem
Nice! Before I'd looked through the code I started thinking this might be useful in avoiding snprintf's unhealthy need to malloc. Then I saw that it uses snprintf. Oh well ;-)
[adding bug-gnulib] iii) fix the gitlog entries -- if that's even viable? I don't think (iii) will work. You can play all sorts of games with filter-branch, but...I managed to screw up three differen
A minor optimization. 2008-03-30 Bruno Haible <address@hidden> * lib/striconveh.h (mem_iconveh, str_iconveh): Optimize the conversion from UTF-8 to UTF-8//TRANSLIT in the same way as from UTF-8 to UT
Here comes the second part of the Unicode string library: charset conversion. It is all built on the striconveha module. 2007-01-26 Bruno Haible <address@hidden> * MODULES.html.sh (Unicode string fun
Nothing about this seems "simple" to me :). I meant "simple" in comparison to the rules like TZ="<-05>+5<-04>,M3.2.0/2,M11.1.0/2". Fixed by installing the attached further patch, which also omits tha
I like Paul's way to disambiguate between More {complex POSIX TZ strings} and {More complex} POSIX TZ strings by use of a hyphen. I also like your, Karl, way to nest double-quotes and sentence syntax
I installed the attached patch to Gnulib Thanks. +Simple POSIX rules like this can also specify nonzero Greenwich offsets. Nothing about this seems "simple" to me :). Anyway. +More-complex POSIX TZ s
$ TZ=UTC-4 date -d 'TZ="UTC" 2022-07-24 15:00' This doesn't mean what you want, because TZ=UTC-4 means "My time zone is abbreviated 'UTC', and it's four hours east of Greenwich" which is not a usefu
If you always write ChangeLog entries before committing, using "vc-dwim --commit" to perform the commit would prevent precisely this problem (among others). I.e., it would have detected the inconsist