Re: [PATCH] math: Silence -Winclude-next-absolute-path warning.

Collin Funk wrote: > gettext warns a lot about that header. I'll submit a patch over there later > today. gettext imports a lot of code from gnulib. Before submitting a patch, check whether the file is present in the gettext git repository [1] (as opposed to the gettext release tarball). If the

Re: [PATCH] math: Silence -Winclude-next-absolute-path warning.

Collin Funk wrote: > Hello. When compiling gettext from master I get the following warning: > > ./math.h:46:2: warning: #include_next in file found relative to primary > source file or found by absolute path; will search from start of include path > [-Winclude-next-absolute-path] >46 |

Re: [PATCH] math: Silence -Winclude-next-absolute-path warning.

On 2/17/24 2:51 AM, Bruno Haible wrote: > I also applied this patch, to complete > : Thanks, gettext warns a lot about that header. I'll submit a patch over there later today.

[PATCH] math: Silence -Winclude-next-absolute-path warning.

Hello. When compiling gettext from master I get the following warning: ./math.h:46:2: warning: #include_next in file found relative to primary source file or found by absolute path; will search from start of include path [-Winclude-next-absolute-path] 46 | #include_next I've attached a

Re: [PATCH] nstrftime: allow opt-out of AM/PM adjustment

On 2024-02-15 13:56, Bruno Haible wrote: The effect of your patch is merely that Emacs users on Solaris or NetBSD, in a French locale (or one of many other locales) will get an AM/PM string attached to their date+time display. Something which is a no-go in such locales, because it goes against

Emacs locking vs. gnulib locking

Paul Eggert wrote: > Emacs has its own idea about locks emacs/src/systhread.c has a similar approach as gnulib regarding locking: it defines an implementation for Unix, and implementation for native Windows, and an implementation for no multithreading at all. I think that locking is ultimately

[PATCH] Solaris EOL update

* doc/solaris-versions: Solaris 11.4 EOL update. Also mention 11.3. --- ChangeLog| 5 + doc/solaris-versions | 6 +++--- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/ChangeLog b/ChangeLog index 6c50c3574d..250db951e5 100644 --- a/ChangeLog +++ b/ChangeLog @@

Re: localtime on native Windows

On 2024-02-17 18:38, Bruno Haible wrote: Note also: The above approach will need locking, in order to protect caches (in 1) the data for a single time zone, in 3) the contents of tzdata.zi). The idea I had was to go more in the NetBSD / TZDB direction. These implementations don't need either

Re: localtime on native Windows

Brian Inglis wrote: > I was looking around ... that required data can be shrunk to ~300KB using > Brotli!? Whereas the entire tzdata.zi (without comments, and with abbreviations) is only around 100 KB. I'll definitely prefer the latter. > Other options would be for some selection of generated

Re: localtime on native Windows

Paul Eggert wrote: > > The first question is how to include tzdata in gnulib. > >- AFAICS, the main data file (without comments) is tzdata.zi and is about > > 100 KB large. It can be upgraded simply by copying the newest tzdata.zi > > from a newer tzdata distribution. Including such

[PATCH] savedir: work around GCC bug 113963

* lib/savedir.c: Ignore -Wanalyzer-malloc-leak and -Wanalyzer-null-dereference. --- ChangeLog | 4 lib/savedir.c | 6 ++ 2 files changed, 10 insertions(+) diff --git a/ChangeLog b/ChangeLog index 250db951e5..4680deb9db 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,9 @@

[PATCH] qsort_r-tests: minor visibility cleanup

* tests/test-qsort_r.c (cmp): Now static. --- ChangeLog| 3 +++ tests/test-qsort_r.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 4680deb9db..f048c91af5 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,8 @@ 2024-02-17 Paul Eggert

Re: localtime on native Windows

On 2024-02-17 19:14, Bruno Haible wrote: Brian Inglis wrote: I was looking around ... that required data can be shrunk to ~300KB using Brotli!? Whereas the entire tzdata.zi (without comments, and with abbreviations) is only around 100 KB. I'll definitely prefer the latter. Other options