how can i generate warnings for implicit casts that lose bits?

[robert bristow-johnson]

here is a post i put out (using Google Groups) that got dropped by
google:

i am using gcc as so:
$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --
enable-checking=releas e --with-system-zlib --enable-__cxa_atexit --
disable-libunwind-exceptions --enable-libgcj-multifile --enable-
languages=c,c++ ,objc,obj-c++,java,fortra n,ada --enable-java-awt=gtk --
disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)

and have compiled a simple test program (FILE: hello.c):

//
// $ gcc -Wconversion -o hello hello.c
// $ hello
//

#include <stdio.h>
main()
{
unsigned long a_ulong = 0; // 32 bit
short a_short_array[128]; // 16 bit each

a_ulong = 1234567;

a_short_array[26] = a_ulong;

printf("%d, %hx, %x, %lx \n", sizeof(a_short_ array),
a_short_array[26], a_short_array[26], a_ulong );
//
// printf output is:
//
// 256, d687, ffffd687, 12d687
//
}

and ran it as so:

$ gcc -Wconversion -o hello hello.c
$ hello

getting output:

256, d687, ffffd687, 12d687

now, i have confirmed that a short is 16 bits and an unsigned long is
32 bits. why does not this line of code:
a_short_array[26] = a_ulong;
generate a warning when i have the -Wconversion or -Wall flags set on
the gcc invocation line?

there is clearly a loss of bits (or a changing of value).

here is what the manual says about it:
from http://gcc.gnu.org/onlinedocs/gcc/Wa...arning-Options
:

-Wconversion
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.

For C++, also warn for conversions between NULL and non-pointer
types; confusing overload resolution for user-defined conversions; and
conversions that will never use a type conversion operator:
conversions to void, the same type, a base class or a reference to
them. Warnings about conversions between signed and unsigned integers
are disabled by default in C++ unless -Wsign-conversion is explicitly
enabled.

is there some other compiler flag i need to hit? i don't get why this
doesn't generate a warning.
finally, please reply to both newsgroups as i don't hang around
comp.lang.c very much.

thank you,

r b-j

[CBFalconer]

Keith Thompson wrote:

CBFalconer <cb********@yah oo.comwrites:
[...]

>At any rate, there is a large difference between:

shortthing = bigthing;
and
shortthing = (shorttype)bigt hing;

in that the second has already performed the conversion, and
nothing is lost thereafter.

Assuming that shortthing is of type shorttype, there's no semantic
difference. The same conversion is performed in both cases; it's
just implicit in the first, and explicit in the second. (And in
the second case, it might be promoted after the cast and then
narrowed for the assignment, but I don't think that can have any
visible effect, and a compiler is likely to optimize it out.)

A compiler might reasonably warn in one case but not in the other,
but there's no requirement for it to do so.

There is no possible reason for a warning in the second. Assigning
a shorttype to shortthing is a completely normal action. There
never is an imperative warning.

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

jacob navia wrote:

CBFalconer wrote:

>Ian Collins wrote:

>>jacob navia wrote:
robert bristow-johnson wrote:

is there some other compiler flag i need to hit? i don't get
why this doesn't generate a warning.
>
Do not know about gcc, but lcc-win32 produces:

Did you have to quote the entire message?

I don't think he cares about normal Usenet protocol. He certainly
ignores topicality here.

Mmm This thread is about a gcc warning. Obviously gcc is
on topic, but lcc-win32 is not.

I was referring to the unnecessary inclusion. F'ups set.

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

CBFalconer <cb********@yah oo.comwrites:

Keith Thompson wrote:

>CBFalconer <cb********@yah oo.comwrites:
[...]

>>At any rate, there is a large difference between:

shortthing = bigthing;
and
shortthing = (shorttype)bigt hing;

in that the second has already performed the conversion, and
nothing is lost thereafter.

Assuming that shortthing is of type shorttype, there's no semantic
difference. The same conversion is performed in both cases; it's
just implicit in the first, and explicit in the second. (And in
the second case, it might be promoted after the cast and then
narrowed for the assignment, but I don't think that can have any
visible effect, and a compiler is likely to optimize it out.)

A compiler might reasonably warn in one case but not in the other,
but there's no requirement for it to do so.

There is no possible reason for a warning in the second. Assigning
a shorttype to shortthing is a completely normal action. There
never is an imperative warning.

There is a *possible* reason to warn about the cast (not about the
assignment). Converting bigthing to shorttype can lose information.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Keith Thompson wrote:

CBFalconer <cb********@yah oo.comwrites:

>Keith Thompson wrote:

>>CBFalconer <cb********@yah oo.comwrites:
[...]
At any rate, there is a large difference between:

shortthing = bigthing;
and
shortthing = (shorttype)bigt hing;

in that the second has already performed the conversion, and
nothing is lost thereafter.

Assuming that shortthing is of type shorttype, there's no semantic
difference. The same conversion is performed in both cases; it's
just implicit in the first, and explicit in the second. (And in
the second case, it might be promoted after the cast and then
narrowed for the assignment, but I don't think that can have any
visible effect, and a compiler is likely to optimize it out.)

A compiler might reasonably warn in one case but not in the other,
but there's no requirement for it to do so.

There is no possible reason for a warning in the second. Assigning
a shorttype to shortthing is a completely normal action. There
never is an imperative warning.

There is a *possible* reason to warn about the cast (not about the
assignment). Converting bigthing to shorttype can lose information.

Agreed, which is what I was trying to point out.

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[robert bristow-johnson]

On Jun 7, 8:51 am, CBFalconer <cbfalco...@yah oo.comwrote:

Keith Thompson wrote:

....

There is a *possible* reason to warn about the cast (not about the
assignment). Converting bigthing to shorttype can lose information.

Agreed, which is what I was trying to point out.

in my opinion, when a programmer uses an explicit cast, the compiler
should be able to assume the guy knows what he is doing (and no
warning necessary). it is the implicit conversions that happen when
one type is assigned to another type or passed as an argument that was
meant to be (and declared as) another type, that might need warnigs.
when we do that without an explicit cast (destination_ty pe) operator,
if and only if there is a possible change of value even if the word
size increased, there should be a warning, or at least the option of
that.

this code:

unsigned long an_unsigned_lon g;
short a_short;
...
an_unsigned_lon g = a_short;

should generate such a warning, even if the bits get bigger.

r b-j

[glen herrmannsfeldt]

robert bristow-johnson wrote:
(snip)

in my opinion, when a programmer uses an explicit cast, the compiler
should be able to assume the guy knows what he is doing (and no
warning necessary). it is the implicit conversions that happen when
one type is assigned to another type or passed as an argument that was
meant to be (and declared as) another type, that might need warnigs.
when we do that without an explicit cast (destination_ty pe) operator,
if and only if there is a possible change of value even if the word
size increased, there should be a warning, or at least the option of
that.

C is intended to be a relatively low level language, and programmers
are assumed to know what they are doing. Traditionally warnings like
you mention might have been generated by lint, though I don't know
that it ever specifically did that one. Too much code has been
written assuming those conversions work. Note, for example, that

short i;
i=i+2;

would give a warning as i+2 is int, converted to short by assignment.

On the other hand, Java requires a cast for all narrowing assignments
as part of the language definition. That is sometimes inconvenient,
but mostly reminds the programmer to think before writing. Java is
not intended to be as (relatively) low level language as C.

-- glen

[Randy Yates]

robert bristow-johnson <rb*@audioimagi nation.comwrite s:

On Jun 7, 8:51 am, CBFalconer <cbfalco...@yah oo.comwrote:

>Keith Thompson wrote:

...

There is a *possible* reason to warn about the cast (not about the
assignment). Converting bigthing to shorttype can lose information.

Agreed, which is what I was trying to point out.

in my opinion, when a programmer uses an explicit cast, the compiler
should be able to assume the guy knows what he is doing (and no
warning necessary). it is the implicit conversions that happen when
one type is assigned to another type or passed as an argument that was
meant to be (and declared as) another type, that might need warnigs.
when we do that without an explicit cast (destination_ty pe) operator,
if and only if there is a possible change of value even if the word
size increased, there should be a warning, or at least the option of
that.

this code:

unsigned long an_unsigned_lon g;
short a_short;
...
an_unsigned_lon g = a_short;

should generate such a warning, even if the bits get bigger.

I agree 100 percent.

And just to establish that I've "been around the C block," this year
marks my 18th year using the language. I've used compilers from multiple
vendors under multiple platforms.
--
% Randy Yates % "She has an IQ of 1001, she has a jumpsuit
%% Fuquay-Varina, NC % on, and she's also a telephone."
%%% 919-577-9882 %
%%%% <ya***@ieee.o rg % 'Yours Truly, 2095', *Time*, ELO
http://home.earthlink.net/~yatescr

[David Thompson]

On Tue, 05 Jun 2007 23:51:14 -0700, jaysome <ja*****@hotmai l.com>
wrote:

On Tue, 05 Jun 2007 15:05:00 -0700, Ben Pfaff <bl*@cs.stanfor d.edu>
wrote:

This statement reflects some confusion about C definitions. In
C, a char is always one byte, in that sizeof(char) is always 1.
However, the size of a byte is implementation-defined: it may be
larger than one octet (though not smaller).

The C standard screwed up when it chose to use the term "byte" to
refer to what is really a storage unit. Everyone who owns a hard drive
knows that a byte is 8 bits. So do most programmers, regardless of
their programming language choice.

Not people who own (or owned) the drives or disks used on PDP-10 or
-6, PDP-8 or -12, GE-635/645/HIS6180, and at least some CDC machines.
And probably quite a few more, although some of the non-8-bit-byte
machines existed before disks became affordable or even possible.

The Ada standard got it right, because it chose to use the term
"storage unit" to refer to what the C standard refers to as a "byte".
Ada83 pre-dates C90 by enough years--go figure.

An IMNVHO underappreciate d benefit of Ada is that its terminology and
particularly language keywords was carefully chosen -- admittedly
starting from a clean slate -- to not only be precise _and_ clear, but
to fit together well. IME it's the only serious language other than
COBOL in which one can write reasonably good code that also reads as
tolerable prose. (I consider Knuth's literate programming a
superstructure/methodology rather than a language as such.)

- formerly david.thompson1 || achar(64) || worldnet.att.ne t

[Jerry Avins]

David Thompson wrote:

An IMNVHO underappreciate d benefit of Ada is that its terminology and
particularly language keywords was carefully chosen -- admittedly
starting from a clean slate -- to not only be precise _and_ clear, but
to fit together well. IME it's the only serious language other than
COBOL in which one can write reasonably good code that also reads as
tolerable prose. ...

Forth?

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯ ¯Â¯Â¯Â¯Â¯Â¯Â¯Â¯ ¯¯¯¯¯¯¯ ¯Â¯Â¯Â¯Â¯Â¯Â¯Â¯ ¯¯¯¯¯¯¯ ¯Â¯Â¯Â¯Â¯Â¯Â¯Â¯ ¯¯¯¯¯¯¯ ¯Â¯Â¯Â¯Â¯Â¯Â¯Â¯ ¯¯¯¯¯¯¯ ¯Â¯Â¯Â¯

[CBFalconer]

Jean-Marc Bourguet wrote:

>

.... snip ...

>
The DEC PDP-10 had instructions to manipulate bytes (again the
architecture description use the term byte) whose width was
anything between 1 and 36 bits and was commonly used with ASCII
7 bits character (yes, there was a lost bit per word).

And the janitors made a fortune sweeping up those bits and hawking
them as PDP 11 memory. They were the heart of the bit serial PDP
11 model.

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com