On 1/14/21 3:44 AM, Adhemerval Zanella wrote:
I think we still should fix BZ#14185 with the suggested with the strategy of
falling back to non wide mode in case of encoding error.
For glibc 2.33 that's likely the best we can do.
The full fix will take some time, since it is pretty much a
Bruno Haible writes:
> You are supposed to choose the warnings that are reasonable for your
> project. For some project of mine, I had to disable 20-40 warning options
> before I could get reasonable output.
That's exactly what I did :-) The set of warnings enabled in those
commands is the
Alexandre Duret-Lutz writes:
> Bruno Haible writes:
>
>> in C++, it is easier and more robust to define GNULIB_NAMESPACE.
>
> OK, thanks, I'll progress this way.
Progress is not smooth. This time it's unrelated to -Werror.
Using clang++ 11, compilation fails because of the overloads of
On 13/01/2021 16:25, Paul Eggert wrote:
> 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
Hi Bruno!
Bruno Haible writes:
> in C++, it is easier and more robust to define GNULIB_NAMESPACE.
OK, thanks, I'll progress this way.
>> /usr/sbin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/bits/basic_string.h:6652:50:
>> error: The symbol ::vsnprintf refers to
* Bruno Haible:
> 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
