Hi
Testing my updated version of gnulib (as specified yesterday
in https://lists.gnu.org/archive/html/bug-gnulib/2021-01/msg00177.html)
I ran into the following linking issue, which I did not have 8 months ago.
/usr/bin/i686-w64-mingw32-ld: misc/.libs/libmisc.a(satsolver.o): in function
On Tue, Jan 12, 2021 at 3:19 PM Bruno Haible wrote:
>
> Hi Alexandre,
>
> > I'm upgrading a project that used a 8-month-old copy of gnulib to
> > today's version
>
> Since then, gnulib has improved its support for clang.
>
> > I compile with -Werror.
>
> Gnulib generally does not support -Werror
* Paul Eggert:
> By the way, how important is it to support awful encodings like
> shift-JIS that contain bytes that look like '\'? If we don't have to
> support these encodings any more, things get a bit easier. (Asking for
> a friend. :-)
There is a Shift-JIS variant which is
On 1/5/21 10:58 AM, Adhemerval Zanella wrote:
The idea of removing the alloca allows a slight better code generation,
simplifies the boilerplate code to avoid the unbounded alloca usage,
and it plays better with security compiler mitigation tools (such as the
ones for stack clash).
Instead of
On 1/5/21 5:07 AM, Adhemerval Zanella wrote:
It seems that gnulib has added the proposed fix with
aed23714d60d91b2abc74be33635c32ddc5132b5 (done in 2005) and just recently
with a glibc merge with 67306f600fe6a3bcf3fbb6d8bf4b8953b74a8fb7 (done in
2020 to sync back glibc changes) it has fallback
On 1/12/21 12:19 PM, Bruno Haible wrote:
Those macros check for
__cpp_static_assert to assume something about _Static_assert, which
seems dubious.
Paul can tell more about this one.
I agree it's dubious.
Also, looking over the current verify.h, it's a little complicated and I
doubt whether
Paul Eggert asked:
> > By the way, how important is it to support awful encodings like
> > shift-JIS that contain bytes that look like '\'? If we don't have to
> > support these encodings any more, things get a bit easier.
Here we are talking about locale encodings, and Shift_JIS (as well as
Hi Akim,
> Here's my proposal. Feel free to edit it at will.
Looks good to me. Except that I would change the title to mention Gnulib.
> # A set of bitset implementations
How about:
# Gnulib provides versatile bit-set implementations
?
Then please go ahead and post it from
Hi Paul,
> Also, looking over the current verify.h, it's a little complicated and I
> doubt whether the complexity is worth it nowadays. How about if we
> simplify the C++ case, by simply relying on __cpp_static_assert there?
> Although this could miss opportunities for generating diagnostics
On 1/13/21 5:21 PM, Bruno Haible wrote:
For example, say, someone use g++ version >= 5 with option -std=c++98. Then,
with your new code, __cpp_static_assert will be undefined,
_GL_HAVE__STATIC_ASSERT will be 1, and _GL_VERIFY(R, DIAGNOSTIC, ...) will
expand to
_Static_assert (R, DIAGNOSTIC)
Paul Eggert wrote:
> How about the attached, more-conservative patch instead? It limits
> __cpp_static_assert to controlling the use of 'static_assert', and
> causes C++ code to not use _Static_assert at all.
This one looks good. I agree that most C++ compilers have or will have
Hi Alexandre,
> I ran into the following linking issue, which I did not have 8 months ago.
>
> /usr/bin/i686-w64-mingw32-ld: misc/.libs/libmisc.a(satsolver.o): in function
> `ZNSt13basic_filebufIcSt11char_traitsIcEED4Ev':
> /usr/lib/gcc/i686-w64-mingw32/10-posix/include/c++/fstream:249:
Florian Weimer writes:
> Would you be able to check whether __null is in the preprocessed
> sources? If it is there (and the lack of further logged expansions
> suggests this), then this is a compiler bug. __null is not zero, and
> should be fine to use as a null pointer constant. This is why
Hi. I have pushed this, see background here:
https://lists.gnutls.org/pipermail/gnutls-devel/2016-October/008183.html
https://savannah.gnu.org/support/?107874
/Simon
From a8bac4d4940cd7c7eeef85f3c618a78a274f0cb8 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Wed, 13 Jan 2021 14:38:20
14 matches
Mail list logo
