Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
Is it really permitted to have sizeof (size_t) sizeof (unsigned int)?
...
The offending warning breaks coreutils' `make distcheck' rule.
Would it make sense to rewrite coreutils 'make distcheck' to filter
out the
Jim Meyering [EMAIL PROTECTED] wrote:
Paul Eggert [EMAIL PROTECTED] wrote:
It will take a while for this [gcc] fix to propagate, though. In the
Is there a patch yet to make gcc suppress that warning?
FYI, here is the warning again
[line 586 referred to the test in the expansion of
Jim Meyering [EMAIL PROTECTED] writes:
Is there a patch yet to make gcc suppress that warning?
Sorry, not yet. Other things are on my plate
- unsigned int n1 = n0 + 1;
+ /* FIXME: technically, the type of n1 should be `unsigned int',
+ but that evokes an unsuppressible
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
Is there a patch yet to make gcc suppress that warning?
Sorry, not yet. Other things are on my plate
- unsigned int n1 = n0 + 1;
+ /* FIXME: technically, the type of n1 should be `unsigned int',
+
Jim Meyering [EMAIL PROTECTED] writes:
Is it really permitted to have sizeof (size_t) sizeof (unsigned int)?
Yes, I'm afraid so. The C Standard merely says that size_t is an
unsigned integer type; size_t is allowed to be narrower than unsigned int.
See, for example, Mark Brader's 10-year-old
Paul Eggert wrote:
Shouldn't we simply fix GCC instead?
I agree. The appended simpler test case (with 'unsigned short' instead of
'unsigned int', to see the warning on a 32-bit platform as well) produces
the warning with gcc -Wall, even without -W, with any of 3.3.1, 3.4.3,
4.0.0.
It appears
Paul Eggert [EMAIL PROTECTED] wrote:
It will take a while for this fix to propagate, though. In the
meantime, why not modify the definition of xalloc_oversized(n,s) to
always return 0 if if s is a constant and if the size of n is such
that the comparison cannot possibly fail. Something like
Jim Meyering [EMAIL PROTECTED] writes:
Oskar Liljeblad [EMAIL PROTECTED] wrote:
What's the proper way to fix these warnings?
quotearg.c: In function `quotearg_n_options':
quotearg.c:586: warning: comparison is always false due to limited range of
data type
Paul, if you don't find a way to
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
Oskar Liljeblad [EMAIL PROTECTED] wrote:
What's the proper way to fix these warnings?
quotearg.c: In function `quotearg_n_options':
quotearg.c:586: warning: comparison is always false due to limited range of
data
On Wednesday, June 22, 2005 at 11:50, Jim Meyering wrote:
Isn't that a cure that is worse than the disease? That patch will
slow down the code on his platform, by causing the compiler to insert
a run-time check where it now does the check at compile-time (and can
therefore omit the call
Oskar Liljeblad [EMAIL PROTECTED] wrote:
On Wednesday, June 22, 2005 at 11:50, Jim Meyering wrote:
...
These days, I rarely use -W (and never use it with -Werror),
for precisely that reason.
I get that warning without both -W and -Wall, I think.
(gcc 3.3.6)
I've tried with the following
On Wednesday, June 22, 2005 at 13:47, Jim Meyering wrote:
I get that warning without both -W and -Wall, I think.
(gcc 3.3.6)
I've tried with the following versions of gcc on x86_64-unknown-linux-gnu:
gcc-3.3 (GCC) 3.3.6 (Debian 1:3.3.6-6)
gcc-3.4 (GCC) 3.4.5 20050605 (prerelease)
Oskar Liljeblad [EMAIL PROTECTED] wrote:
On Wednesday, June 22, 2005 at 13:47, Jim Meyering wrote:
I get that warning without both -W and -Wall, I think.
(gcc 3.3.6)
I've tried with the following versions of gcc on x86_64-unknown-linux-gnu:
gcc-3.3 (GCC) 3.3.6 (Debian 1:3.3.6-6)
Paul Eggert [EMAIL PROTECTED] wrote:
Oskar Liljeblad [EMAIL PROTECTED] wrote:
...
quotearg.c: In function `quotearg_n_options':
quotearg.c:586: warning: comparison is always false due to limited range of
data type
...
My own experience is that that particular warning is more trouble
than
Jim Meyering [EMAIL PROTECTED] writes:
Besides, who knows... compilers may eventually be able to optimize
away that xalloc_die call, in spite of the intermediate size_t.
If GCC ever gets that smart, then it will issue the same
warning as it does now without the unsigned_int hack.
Shouldn't we
Oskar Liljeblad [EMAIL PROTECTED] wrote:
What's the proper way to fix these warnings?
quotearg.c: In function `quotearg_n_options':
quotearg.c:586: warning: comparison is always false due to limited range of
data type
Paul, if you don't find a way to eliminate the warning by changing
16 matches
Mail list logo
