On 2023-02-04 15:37, Reuben Thomas wrote:
Bruno pointed out to me that there's a bug fixed in the Makfile.in.in from
gettext 0.20.2, which postdates the 0.20 version found in gnulib. (The bug
is that the Makefile.in.in has prerequisites on suffix rules, which are
ignored.)
In Gnulib I'd normall
Bruno pointed out to me that there's a bug fixed in the Makfile.in.in from
gettext 0.20.2, which postdates the 0.20 version found in gnulib. (The bug
is that the Makefile.in.in has prerequisites on suffix rules, which are
ignored.)
--
https://rrt.sc3d.org
> On 4 Feb 2023, at 22:03, Paul Eggert wrote:
>
> On 2023-02-04 12:23, Sam James wrote:
>> I guess it's hard for me to say given I don't know what options allowed it
>> to be reproduced and I couldn't hit it.
>> I assumed it must have been -Wstrict-aliasing=2 or lower which makes it more
>> a
On 2023-02-04 12:23, Sam James wrote:
I guess it's hard for me to say given I don't know what options allowed it to
be reproduced and I couldn't hit it.
I assumed it must have been -Wstrict-aliasing=2 or lower which makes it more
aggressive at the risk of false positives.
But if you reproduce
Bruno has been helping me test https://github.com/rrthomas/libpaper on
various systems. (Many thanks, Bruno!)
On Wed, 1 Feb 2023 at 12:39, Bruno Haible wrote:
> On GNU/Hurd and Cygwin, I see 9 test failures. Such as
>
> --- expected-fixed.txt 2023-02-01 03:02:44.0 +0100
> +++ default-si
On Sat, 4 Feb 2023 at 21:18, Simon Josefsson wrote:
>
> To automatically understand if a cc to the translation project is
> necessary or not, I think we'd need access to the previously sent pot
> file, no? I guess we could wget that from somewhere and compare it, but
> that seems a bit fragile.
Reuben Thomas writes:
> Using the standard gnulib release procedure for GNU projects,
> coordina...@translationproject.org is automatically emailed for each
> release, but apparently this is not desired. I received this from Benno
> Schulenberg :
>
> My scripts find zero changes in the msgids.
>>
> On 4 Feb 2023, at 20:20, Paul Eggert wrote:
>
> On 2023-02-04 11:53, Sam James wrote:
>> I'd consider using #pragma GCC ... to suppress -Wuse-after-free
>> for the "problematic" lines instead. It'd avoid the risk of either
>> optimisations or sanitisers
>> respectively causing us pain in fut
On 2023-02-04 11:53, Sam James wrote:
I'd consider using #pragma GCC ... to suppress -Wuse-after-free
for the "problematic" lines instead. It'd avoid the risk of either
optimisations or sanitisers
respectively causing us pain in future.
I don't see why that pragma would avoid those problems. A
> On 4 Feb 2023, at 18:46, Paul Eggert wrote:
>
> I manually inspected fts.c to look for violations of the C standard that
> might draw GCC's attention, and installed the attached patches into Gnulib.
> As you can see, they don't fix the technical violations of the C standard.
> However, I h
I manually inspected fts.c to look for violations of the C standard that
might draw GCC's attention, and installed the attached patches into
Gnulib. As you can see, they don't fix the technical violations of the C
standard. However, I hope they keep GCC happy. Please give them a try
with "GCC 1
I am maintaining a2ps, and have recently been making frequent alpha
releases as I attempt to stabilise the result of a massive updating effort
after a long period of quiescence.
The most recent release involves no changes to the gettext strings.
Using the standard gnulib release procedure for GNU
> On 3 Feb 2023, at 22:11, Paul Eggert wrote:
>
> On 2023-02-03 12:24, Peter Frazier wrote:
>> dangling pointers & gcc 13.1
>> problem with:
>> coreutils/gnulib, fts.c
>> compilation failure:
>> -Werror=use-after-free error
>> approach to resolution (thus far):
>> post free of vars, I set the v
After strengthening the C++ tests of , I get compilation errors
on macOS 12.5, such as:
In file included from ../../gltests/test-assert-h-c++.cc:26:
In file included from
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/iostream:37:
In file included from
/Library/Developer/
Some of the C++ tests that I added on 2019-12-05 were not actually active,
i.e. the option '--with-c++-tests' would miss them, since it operates on
module dependencies, without built-in knowledge about module names. The
only built-in knowledge about tests modules that gnulib-tool has is that
FOO de
15 matches
Mail list logo
