Hi,
I've released a new stable snapshot. See attached NEWS.stable for details.
Tarball: http://erislabs.net/ianb/projects/gnulib/gnulib-20120404-stable.tar.gz
Gitweb: http://erislabs.net/gitweb?p=gnulib.git;a=shortlog;h=refs/heads/stable
Git: git://erislabs.net/gnulib.git tag: stable/20120404
On 04/05/2012 04:10 AM, Bruno Haible wrote:
> This patch will not help to fix Daniel Berrange's problem. In mingw
> and mingw64, ssize_t is defined by , and gnulib will not
> override it.
>
> Test program:
> foo.c =
> #include
> size_t a;
> ssize_t b;
> =
On 06.04.2012 00:14, Paul Eggert wrote:
> On 04/05/2012 03:06 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>
>> I mean updating the pot file used at
>> http://translationproject.org/domain/gnulib.html
> Ah, in that case you can just contact the Translation Project directly.
How do I generate .p
On 04/05/2012 03:06 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> I mean updating the pot file used at
> http://translationproject.org/domain/gnulib.html
Ah, in that case you can just contact the Translation Project directly.
> Are you aware of the "new" method:
> http://www.gnu.org/softwar
On 05.04.2012 23:58, Paul Eggert wrote:
> On 04/05/2012 10:26 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> Currently GRUB uses the "old" way of gnulib translation (importing into
>> our domain) but we'll change for the next release. With that there are
>> however 2 issues:
>> 1) It seems tha
On 04/05/2012 10:26 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Currently GRUB uses the "old" way of gnulib translation (importing into
> our domain) but we'll change for the next release. With that there are
> however 2 issues:
> 1) It seems that gnulib TP uploads are relatively rare and ev
Hi Vladimir,
> it is best to split the test into two parts: a part
> > that can be executed on every machine, and a part which can only be executed
> > on a system with a UTF-8 locale. This way, the first part is not skipped
> > just because the system has no UTF-8 locale.
>
> Ok, will do. Can I i
Eric Blake wrote:
> Then how do I explain the compiler
> warning that Daniel was seeing under mingw64?
They come from disagreements regarding the "integer conversion rank" of
'size_t' and 'ssize_t' between GCC and .
When you write printf("%zd",arg) then GCC compares its own built-in knowledge
abo
I hope I hooked it in correctly. Couldn't check yet
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
diff --git a/lib/argp-fmtstream.c b/lib/argp-fmtstream.c
index 70e3eb8..2db995c 100644
--- a/lib/argp-fmtstream.c
+++ b/lib/argp-fmtstream.c
@@ -29,9 +29,11 @@
#include
#include
#include
+#
On 05.04.2012 21:18, Bruno Haible wrote:
> - test-mbsstr2.c is a test that requires a UTF-8 locale. We use the
> French one for simplicity. (If a system does not have fr_FR.UTF-8
> installed, it would be unlikely that it has ru_RU.UTF-8 installed.)
Actually not so true. In case of Debian
> Please take a look how it's done in module 'mbsstr-tests':
> - test-mbsstr1.c is a test that doesn't need a particular locale.
> - test-mbsstr2.c is a test that requires a UTF-8 locale. We use the
>French one for simplicity. (If a system does not have fr_FR.UTF-8
>installed, it would b
On 05.04.2012 21:18, Bruno Haible wrote:
> Hi Vladimir,
> mbsnwidth returns -1 in such a case only if the option MBSW_REJECT_INVALID
> is passed as third argument. If you pass 0, mbsnwidth will not return -1;
> instead, it will assume width 1 for every invalid byte or unprintable
> character.
Ok, w
Hi Vladimir,
> > - The functions __argp_get_display_len and add_length don't write to
> > the memory delimited by 'beg', 'end', 'ptr, 'end'. Therefore it is good
> > style to declare these parameters as being 'const char *' rather than
> > 'char *'. The general rule of thumb is: Use 'const c
On 05.04.2012 17:58, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 05.04.2012 14:32, Bruno Haible wrote:
>
> Remaining is the issue due to escape sequences.
Fixed patch. Now with highlight sequence support.
>> - You have shown a test case as a Cyrillic string. But what is the C code
>> to mak
Currently GRUB uses the "old" way of gnulib translation (importing into
our domain) but we'll change for the next release. With that there are
however 2 issues:
1) It seems that gnulib TP uploads are relatively rare and even now
there are few strings which are in git but not on TP. For the release
On 05.04.2012 14:32, Bruno Haible wrote:
> Hi Vladimir,
>
>> I'm not sure if previous time I sent with or without \0 bugfix. Resending
>
>
> - The function __argp_get_display_len looks very similar to mbsnwidth(),
> from module 'mbswidth'. Could you use that function? One of the gnulib
> princi
On 05.04.2012 14:32, Bruno Haible wrote:
> - The function __argp_get_display_len looks very similar to mbsnwidth(),
> from module 'mbswidth'. Could you use that function? One of the gnulib
> principles is to reuse code that is already in gnulib, where it makes sense.
I've noticed another proble
On 05.04.2012 14:32, Bruno Haible wrote:
> Hi Vladimir,
>
>> I'm not sure if previous time I sent with or without \0 bugfix. Resending
> Thanks. I apologize for not following up on the update that you sent in
> [1] and the test case in [2].
>
> The approach of the patch looks fine now; but there ar
On 04/05/2012 01:30 PM, Křištof Želechovski wrote:
> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=lib/copy-
> file.c >
>
> has IO_SIZE = 32 * 1024
>
> This number is used to specify the buffer length for copying data from one
> file to another, something that neither ANSI C n
On 04/05/2012 07:05 AM, Daniel P. Berrange wrote:
> On Thu, Apr 05, 2012 at 06:07:20AM -0600, Eric Blake wrote:
>> On 04/05/2012 04:10 AM, Bruno Haible wrote:
>> You forgot to check one (64-bit mingw64):
>>
>> $ x86_64-w64-mingw32-gcc -E foo.c | grep size_t
>> __extension__ typedef unsigned long lo
On Thu, Apr 05, 2012 at 06:07:20AM -0600, Eric Blake wrote:
> On 04/05/2012 04:10 AM, Bruno Haible wrote:
> You forgot to check one (64-bit mingw64):
>
> $ x86_64-w64-mingw32-gcc -E foo.c | grep size_t
> __extension__ typedef unsigned long long size_t;
> __extension__ typedef long long ssize_t;
>
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=lib/copy-
file.c >
has IO_SIZE = 32 * 1024
This number is used to specify the buffer length for copying data from one
file to another, something that neither ANSI C nor POSIX directly supports.
It is not configurable. How was tha
Hi Vladimir,
> I'm not sure if previous time I sent with or without \0 bugfix. Resending
Thanks. I apologize for not following up on the update that you sent in
[1] and the test case in [2].
The approach of the patch looks fine now; but there are a couple of minor
problems that would be nice to
More about security warnings and style warnings:
> So, the warning "format not a string literal and no format arguments" or,
> more generally "format with no format arguments", is a *style* warning,
> not a *security* warning.
The idea is that security warnings are about situations that are dange
Gilles Espinasse wrote:
> Remove the code hack preventing format-zero-length warning and replace by a
> pragma GCC diagnostic ignored in top of code.
This patch is not good, because the warning "zero-length format string"
exists at least since GCC 3.1, however
'#pragma GCC diagnostic ignored "-Wfo
Hi Eric,
> We were blindly defining ssize_t to int. On mingw64, this is the
> correct size, but the wrong rank, which leads gcc to issue warnings
> for %zd printf directives.
>
> * m4/ssize_t.m4 (gt_TYPE_SSIZE_T): Match rank of size_t.
This patch will not help to fix Daniel Berrange's problem. I
26 matches
Mail list logo
