Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #21888 > unrolled thread

Why no warning?

Back to article view | Back to comp.lang.c

Contents

  Why no warning? Hill Pang <pangbw@gmail.com> - 2012-06-06 02:42 -0700
    Re: Why no warning? Noob <root@127.0.0.1> - 2012-06-06 12:04 +0200
      Re: Why no warning? Hill Pang <pangbw@gmail.com> - 2012-06-06 03:17 -0700
        Re: Why no warning? James Kuyper <jameskuyper@verizon.net> - 2012-06-06 06:29 -0400
          Re: Why no warning? Noob <root@127.0.0.1> - 2012-06-06 12:54 +0200
    Re: Why no warning? David Brown <david@westcontrol.removethisbit.com> - 2012-06-06 12:28 +0200
      Re: Why no warning? Noob <root@127.0.0.1> - 2012-06-06 12:55 +0200
        Re: Why no warning? David Brown <david@westcontrol.removethisbit.com> - 2012-06-06 13:17 +0200
    Re: Why no warning? Hill Pang <pangbw@gmail.com> - 2012-06-06 04:35 -0700
      Re: Why no warning? James Kuyper <jameskuyper@verizon.net> - 2012-06-06 08:56 -0400
        Re: Why no warning? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-06-07 15:05 +0000
    Re: Why no warning? China Blue Max <chine.bleu@yahoo.com> - 2012-06-06 04:53 -0700
      Re: Why no warning? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-06 13:29 +0100
        Re: Why no warning? Willem <willem@toad.stack.nl> - 2012-06-06 13:07 +0000
          Re: Why no warning? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-06 17:37 +0100
    Re: Why no warning? Ralph Spitzner <rasp@spitzner.org> - 2012-06-06 16:57 +0200
      Re: Why no warning? James Kuyper <jameskuyper@verizon.net> - 2012-06-06 11:20 -0400
      Re: Why no warning? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-06 17:45 +0100

#21888 — Why no warning?

I was expecting a warning for this assignment, but can't get from GCC, why? isn't it an overflow?
 
char c = 0xff;

[toc] | [next] | [standalone]

#21890

Hill Pang wrote:

> I was expecting a warning for this assignment, but can't get from GCC, why?
> isn't it an overflow?
>  
> char c = 0xff;

1) consider the gcc options -fsigned-char and -funsigned-char
and ask yourself: "is char a signed or unsigned type?"

2) consider the gcc option -Wstrict-overflow=n
(-Wall enables -Wstrict-overflow=1)
Note however that "overflow" only makes sense in the context
of signed arithmetic, since the language properly defines the
"wrap-around" semantics for unsigned arithmetic.

[toc] | [prev] | [next] | [standalone]

#21891

On Wednesday, June 6, 2012 6:04:09 PM UTC+8, Noob wrote:
> Hill Pang wrote:
> 
> > I was expecting a warning for this assignment, but can't get from GCC, why?
> > isn't it an overflow?
> >  
> > char c = 0xff;
> 
> 1) consider the gcc options -fsigned-char and -funsigned-char
> and ask yourself: "is char a signed or unsigned type?"
> 
> 2) consider the gcc option -Wstrict-overflow=n
> (-Wall enables -Wstrict-overflow=1)
> Note however that "overflow" only makes sense in the context
> of signed arithmetic, since the language properly defines the
> "wrap-around" semantics for unsigned arithmetic.

1) I am running the GCC on X86, I am sure by default the char should be signed, and even I add the option -fsigned-char, the result is same.
2) I tried -Wall and -Wstrict-overflow=1, no luck to get the warning.

[toc] | [prev] | [next] | [standalone]

#21892

On 06/06/2012 06:17 AM, Hill Pang wrote:
> On Wednesday, June 6, 2012 6:04:09 PM UTC+8, Noob wrote:
>> Hill Pang wrote:
>>
>>> I was expecting a warning for this assignment, but can't get from GCC, why?
>>> isn't it an overflow?
>>>  
>>> char c = 0xff;
>>
>> 1) consider the gcc options -fsigned-char and -funsigned-char
>> and ask yourself: "is char a signed or unsigned type?"
>>
>> 2) consider the gcc option -Wstrict-overflow=n
>> (-Wall enables -Wstrict-overflow=1)
>> Note however that "overflow" only makes sense in the context
>> of signed arithmetic, since the language properly defines the
>> "wrap-around" semantics for unsigned arithmetic.
> 
> 1) I am running the GCC on X86, I am sure by default the char should be signed, and even I add the option -fsigned-char, the result is same.
> 2) I tried -Wall and -Wstrict-overflow=1, no luck to get the warning.

You need the -pedantic option:

gcc -pedantic -c overchar.c
overchar.c:1: warning: overflow in implicit constant conversion
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#21894

James Kuyper wrote:

> You need the -pedantic option:
> 
> gcc -pedantic -c overchar.c
> overchar.c:1: warning: overflow in implicit constant conversion

Alternatively, one may consider -Wsign-conversion:
> Warn for implicit conversions that may change the sign of an integer
> value, like assigning a signed integer expression to an unsigned
> integer variable. An explicit cast silences the warning.

Or rather -Wconversion in this specific scenario:
> Warn for implicit conversions that may alter a value. This includes
> conversions between real and integer, like abs (x) when x is double;
> conversions between signed and unsigned, like unsigned ui = -1; and
> conversions to smaller types, like sqrtf (M_PI). Do not warn for
> explicit casts like abs ((int) x) and ui = (unsigned) -1, or if the
> value is not changed by the conversion like in abs (2.0). Warnings
> about conversions between signed and unsigned integers can be
> disabled by using -Wno-sign-conversion.

$ gcc -Wconversion -c warn.c
warn.c: In function 'foo':
warn.c:3:3: warning: conversion to 'char' alters 'int' constant value

[toc] | [prev] | [next] | [standalone]

#21893

On 06/06/2012 11:42, Hill Pang wrote:
> I was expecting a warning for this assignment, but can't get from
> GCC, why? isn't it an overflow?
>
> char c = 0xff;

I'll give you a warning if you like :-)

A "char" is for holding a "character", or letter.

If you want a small variable (typically 8-bit on most architectures) for 
holding a number, use "uint8_t" or "int8_t" as required.

"uint8_t c = 0xff;" gives no warning.

[toc] | [prev] | [next] | [standalone]

#21895

David Brown wrote:

> I'll give you a warning if you like :-)
> 
> A "char" is for holding a "character", or letter.
> 
> If you want a small variable (typically 8-bit on most architectures) for 
> holding a number, use "uint8_t" or "int8_t" as required.
> 
> "uint8_t c = 0xff;" gives no warning.

Does int8_t c = 0xff; give one? :-)

[toc] | [prev] | [next] | [standalone]

#21896

On 06/06/2012 12:55, Noob wrote:
> David Brown wrote:
>
>> I'll give you a warning if you like :-)
>>
>> A "char" is for holding a "character", or letter.
>>
>> If you want a small variable (typically 8-bit on most architectures) for
>> holding a number, use "uint8_t" or "int8_t" as required.
>>
>> "uint8_t c = 0xff;" gives no warning.
>
> Does int8_t c = 0xff; give one? :-)

It would give you another warning from me!

To get a warning from the compiler, you would (as others have said) need 
-Wconversion or -Wsign-conversion.  I use those sorts of flags, but I 
use more warning flags than most people.

[toc] | [prev] | [next] | [standalone]

#21897

On Wednesday, June 6, 2012 5:42:13 PM UTC+8, Hill Pang wrote:
> I was expecting a warning for this assignment, but can't get from GCC, why? isn't it an overflow?
>  
> char c = 0xff;

Thanks, every one!

Yes, with additional options, the warning shows, but for me I think it is straight to check if a const is in the represent-able range of a variable in an assignment, I think the warning should be popped up by default rather by an extra option. I am wondering if there is some special rulers behind this, is there any such ruler listed in the C standard or some place anywhere?

[toc] | [prev] | [next] | [standalone]

#21901

On 06/06/2012 07:35 AM, Hill Pang wrote:
> On Wednesday, June 6, 2012 5:42:13 PM UTC+8, Hill Pang wrote:
>> I was expecting a warning for this assignment, but can't get from GCC, why? isn't it an overflow?
>>  
>> char c = 0xff;
> 
> Thanks, every one!
> 
> Yes, with additional options, the warning shows, but for me I think it is straight to check if a const is in the represent-able range of a variable in an assignment, I think the warning should be popped up by default rather by an extra option. I am wondering if there is some special rulers behind this, is there any such ruler listed in the C standard or some place anywhere?

The C standard mandates certain diagnostics. gcc does not provide all of
the mandated diagnostics for any version of the C standard (and is
therefore not a conforming implementation of C) without either the -ansi
or the -std= options, plus -pedantic. There's LOTS of additional useful
warnings not mandated by the C standard, and you need to explicitly
request them; -Wall gets most of the most useful ones. I like to add
-Wpointer-arith -Wcast-align -Wstrict-prototypes -Wmissing-prototypes

[toc] | [prev] | [next] | [standalone]

#21932

On Wed, 2012-06-06, James Kuyper wrote:
> On 06/06/2012 07:35 AM, Hill Pang wrote:
>> On Wednesday, June 6, 2012 5:42:13 PM UTC+8, Hill Pang wrote:
>>> I was expecting a warning for this assignment, but can't get from GCC, why? isn't it an overflow?
>>>  
>>> char c = 0xff;
>> 
>> Thanks, every one!
>> 
>> Yes, with additional options, the warning shows, but for me I think it is straight to check if a const is in the represent-able range of a variable in an assignment, I think the warning should be popped up by default rather by an extra option. I am wondering if there is some special rulers behind this, is there any such ruler listed in the C standard or some place anywhere?
>
> The C standard mandates certain diagnostics. gcc does not provide all of
> the mandated diagnostics for any version of the C standard (and is
> therefore not a conforming implementation of C) without either the -ansi
> or the -std= options, plus -pedantic. There's LOTS of additional useful
> warnings not mandated by the C standard, and you need to explicitly
> request them; -Wall gets most of the most useful ones. I like to add
> -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wmissing-prototypes

Another data point: my Makefiles almost always say
  CFLAGS=-Wall -Wextra -pedantic -std=c99 -g -O3
(with some variations on the -O level).

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#21898

In article <6d2a019d-fea9-406d-9cda-e0d77566f4e6@googlegroups.com>,
 Hill Pang <pangbw@gmail.com> wrote:

> I was expecting a warning for this assignment, but can't get from GCC, why? 
> isn't it an overflow?
>  
> char c = 0xff;

Either char is implicitly unsigned or it used the conversion unsigned->signed of 
the same size. Unless explicitly marked, the implementation decides whether 
chars are signed; one of the default conversions is unsigned to signed of the 
same size.

-- 
My name Indigo Montoya.      |                     The Dude abides.
You flamed my father.        |       I'm whoever you want me to be.
Prepare to be spanked.       |  Annoying Usenet one post at a time.
Stop posting that!           |    At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

#21900

China Blue Max <chine.bleu@yahoo.com> writes:

> In article <6d2a019d-fea9-406d-9cda-e0d77566f4e6@googlegroups.com>,
>  Hill Pang <pangbw@gmail.com> wrote:
>
>> I was expecting a warning for this assignment, but can't get from GCC, why? 
>> isn't it an overflow?
>>  
>> char c = 0xff;
>
> Either char is implicitly unsigned or it used the conversion
> unsigned->signed of the same size. Unless explicitly marked, the
> implementation decides whether chars are signed; one of the default
> conversions is unsigned to signed of the same size.

Unless I've missed what you mean by "default conversions" that's a
little confusing simply by being overly specific.  C specifies implicit
conversions between unsigned and signed types of all sizes.  Some are
defined entirely by the standard, and others are left up to the
implementation, but there is nothing special about conversion between
signed and unsigned integer types of the same size.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#21903

Ben Bacarisse wrote:
) China Blue Max <chine.bleu@yahoo.com> writes:
)
)> In article <6d2a019d-fea9-406d-9cda-e0d77566f4e6@googlegroups.com>,
)>  Hill Pang <pangbw@gmail.com> wrote:
)>
)>> I was expecting a warning for this assignment, but can't get from GCC, why? 
)>> isn't it an overflow?
)>>  
)>> char c = 0xff;
)>
)> Either char is implicitly unsigned or it used the conversion
)> unsigned->signed of the same size. Unless explicitly marked, the
)> implementation decides whether chars are signed; one of the default
)> conversions is unsigned to signed of the same size.
)
) Unless I've missed what you mean by "default conversions" that's a
) little confusing simply by being overly specific.  C specifies implicit
) conversions between unsigned and signed types of all sizes.  Some are
) defined entirely by the standard, and others are left up to the
) implementation, but there is nothing special about conversion between
) signed and unsigned integer types of the same size.

Since when is the literal 0xff an unsigned type?
As far as I can tell, it should be a signed integer, no?


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#21916

Willem <willem@toad.stack.nl> writes:

> Ben Bacarisse wrote:
> ) China Blue Max <chine.bleu@yahoo.com> writes:
> )
> )> In article <6d2a019d-fea9-406d-9cda-e0d77566f4e6@googlegroups.com>,
> )>  Hill Pang <pangbw@gmail.com> wrote:
> )>
> )>> I was expecting a warning for this assignment, but can't get from GCC, why? 
> )>> isn't it an overflow?
> )>>  
> )>> char c = 0xff;
> )>
> )> Either char is implicitly unsigned or it used the conversion
> )> unsigned->signed of the same size. Unless explicitly marked, the
> )> implementation decides whether chars are signed; one of the default
> )> conversions is unsigned to signed of the same size.
> )
> ) Unless I've missed what you mean by "default conversions" that's a
> ) little confusing simply by being overly specific.  C specifies implicit
> ) conversions between unsigned and signed types of all sizes.  Some are
> ) defined entirely by the standard, and others are left up to the
> ) implementation, but there is nothing special about conversion between
> ) signed and unsigned integer types of the same size.
>
> Since when is the literal 0xff an unsigned type?
> As far as I can tell, it should be a signed integer, no?

Yes, I hope I did not imply otherwise.  I should have snipped the
example since it was not what I was talking about.  I just wanted to
point out that there is nothing special about conversions between
"unsigned to signed of the same size".

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#21913

Hill Pang wrote:
> I was expecting a warning for this assignment, but can't get from GCC, why? isn't it an overflow?
>
> char c = 0xff;

You're basically setting c to -127, which is no legal offense :-p
You'll get into trouble if you try to _compare_ this value
to something else....

	-rasp


-- 
See why I hate Windows users?
      All pain, no gain.
	-Howard Chu

[toc] | [prev] | [next] | [standalone]

#21915

On 06/06/2012 10:57 AM, Ralph Spitzner wrote:
> Hill Pang wrote:
>> I was expecting a warning for this assignment, but can't get from GCC, why? isn't it an overflow?
>>
>> char c = 0xff;
> 
> You're basically setting c to -127, which is no legal offense :-p

He thought, for reasonable (but incorrect) reasons, that he was setting
c to 255. When there's a possible difference between common reasonable
(but incorrect) expectations and the way a compiler actually works, a
sufficiently good compiler should warn you, and gcc does do so. It just
needs the right options turned on to do so.

[toc] | [prev] | [next] | [standalone]

#21917

Ralph Spitzner <rasp@spitzner.org> writes:

> Hill Pang wrote:
>> I was expecting a warning for this assignment, but can't get from GCC, why? isn't it an overflow?
>>
>> char c = 0xff;
>
> You're basically setting c to -127, which is no legal offense :-p
> You'll get into trouble if you try to _compare_ this value
> to something else....

Do you really think the OP has a machine that uses sign-and-magnitude
representation and has a signed char type that uses it?  :-) (C on
machines with odd representations of negative numbers often have and
unsigned plain char type).

-- 
Ben.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web