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
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-o
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 `unsig
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 unsuppressi
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 xallo
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
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
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
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
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 (prere
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 foll
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
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 l
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 d
"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
