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. In
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
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 dangerous
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
URL:
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
On 04/05/2012 01:30 PM, Křištof Želechovski wrote:
URL:
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
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 are a
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 problem
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
principles is
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 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 make the
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 char *'
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 be
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 errno.h
#include
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 sys/types.h.
When you write printf(%zd,arg) then GCC compares its own built-in
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 include
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 even
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:
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 .pot for
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 sys/types.h, and gnulib will not
override it.
Test program:
foo.c =
#include sys/types.h
size_t a;
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
21 matches
Mail list logo
