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

[Chris Dollin]

robert bristow-johnson wrote:

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

I'm going to ignore your real problem [1] in favour of criticising your
subject line:

... implicit casts ...

C doesn't have implicit casts. Casts are explicit syntax, `(Type) Expr`.
It has implicit /conversions/.

I'll have another latte now.

[1] Which I see has generated much -- hopefully helpful -- response.

--
"It was the first really clever thing the King had said that day."
/Alice in Wonderland/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[Ian Collins]

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?

--
Ian Collins.

[CBFalconer]

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.

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.

--
<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]

robert bristow-johnson <r...@audioimag ination.comwrit es:

it just seems to me that this conversion qualifies as one that changes
value. then, according to the gcc doc, it should generate a -
Wconversion warning. it's close to an assignment of one type to
another but less severe. for example, if sizeof(unsigned
short)<sizeof(l ong) we know that no value is changed in this
assignment:

unsigned short a_ushort;
long a_long;
a_ushort = 4321;
a_long = a_ushort;

so no warning should be generated, no matter what bits are in
a_ushort, there is no change of value. whereas (assuming
sizeof(short)<s izeof(unsigned long)) this:

short a_short;
unsigned long a_ulong;
a_short = -4321;
a_ulong = a_short;

should generate a warning because there are values in the range of the
type (short) that are not in the type (unsigned long). so even if the
number of bits in the word are increasing in the assignment, this
should generate a -Wcondition warning ...

i meant to say "generate a -Wconversion warning"
On Jun 5, 11:15 pm, Randy Yates <[e-mail] rote:>

From the manual:

-Wconversion Warn if a prototype causes a type conversion that is
different from what would happen to the same argument in the absence
of a prototype. This includes conversions of fixed point to floating
and vice versa, and conversions changing the width or signedness of
a fixed point argument except when the same as the default
promotion.

Also, warn if a negative integer constant expression is implicitly
converted to an unsigned type. For example, warn about the
assignment x = -1 if x is unsigned. But do not warn about explicit
casts like (unsigned) -1.

What do they mean by "prototype" ?

i function prototype (i think that's what they mean) is when you put
at the top of a C file (or in a header file) the declaration such as:

double my_math_functio n(double argument1, long argument2);

(not the semicolen at the end). it can be abbreviated as so:

double my_math_functio n(double, long);

what i like to do is just copy the top line of the function when i
write it, paste it in the header file, tack on a semi-colen to the end
of it and then feel good and smug that i was obeying good coding
practices in C. in CodeWarrior, there is another check box that says
"Require prototypes" and an error will be generated if you define or
call a function without prototyping it. it's just another little type-
checking discipline that can save your ass at a later date.

i remember once, programming a 68K Mac without requiring prototypes,
and i made a simple call to a standard trancendental function (like
sin() or exp()) but i forgot to #include <math.h>. so the calling
function assumed (by default, since there was no prototype) that sin()
returned int which was 16 or 32 bits, but it really returned double or
extended (64 or 80 bits) and placed that return value on the stack
above the PC. so even though it was automatically linked to the math
lib when i built the app, what happened was that the calling program
(my code) did not reserve sufficient space on the stack for the return
value and the called program plopped a big 64 bit or bigger word than
the space that was made and my machine crashed. it was a stupid and
hard bug to fix because i couldn't understand why calling a standard
math function would crash the machine. i actually single-stepped
through this before realizing that i forgot to #include the header
file with the correct prototypes which was the source of the problem.
ever since then, i've become a believer in building projects with
prototypes required (except maybe if the function is defined in the
same C file it is called, and called *only* in that file, and defined
*before* it is called).

No matter what the documentation says or the standards say, I also
find this situation extremely frustrating and counter-productive.

It seems like the compiler emits warnings (or errors) all the time on
type conversions of little consequence, and yet when it comes to
something that causes a real loss of information, it remains silent.

This behaviour ought to be changed.

i agree. it seems to me to be standard that an *implicit* conversion
that potentially changes value (whether or not there is a bit
reduction) should, at least as an option, be flagged. (explicit casts
need not flag a warning, the compiler can assume you knew what you
were doing.) when you are building a big project with a couple
hundred files with interconnected spagetti code and some value got
clobbered (more precisely "clipped" or masked) because one guy thought
we were dealing with shorts and another thought longs (or signed longs
vs. unsigned longs, whatever), we should be informed by the compiler
when such conversions are made, whether in a simple assignment or in
passing a value to a function (that was expecting a slightly different
type).

i'm afraid this is like that stupid MATLAB/Octave indexing thing (all
arrays must start with index 1). it's something that obviously should
be fixed, but those with the where-with-all to fix it will deny that
it's a problem to start with (i guess that's one way to fix a problem
- deny the existence of it).

r b-j

[jacob navia]

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.

Why?

Because linux is cool and windows is not apparently. Or because
anything I say is off topic.

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.

I know that.

[Richard Heathfield]

jacob navia said:

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.

No, gcc is off-topic here, just like lcc-win32 is off-topic here. The
proper course for respondents would have been to examine the source the
OP provided, to see whether the issue could somehow be resolved using
standard C. If not, they should have referred the OP to a gcc-specific
group.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Keith Thompson]

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.

--
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"

[jacob navia]

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.

lcc-win32 does NOT warn when the programmer explicitely casts
the assignment since it assumes that the programmer knows
about that particular data representation and it supposes
that the cast is safe.

When there is an implict conversion however, it could be due
to an oversight or an error, and in that case a warning is
useful.

[robert bristow-johnson]

On Jun 6, 2:28 pm, Richard Heathfield <[e-mail].i nvalidwrote:

jacob navia said:

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.

No, gcc is off-topic here, just like lcc-win32 is off-topic here. The
proper course for respondents would have been to examine the source the
OP provided, to see whether the issue could somehow be resolved using
standard C. If not, they should have referred the OP to a gcc-specific
group.

as the OP, i didn't think this was so off-topic for comp.lang.c (i
cross-posted to comp.dsp because there is where i loiter and i know
that some of those guys think about nasty details like this). it
wasn't until someone pointed me to gnu.gcc.somethi ng that i had any
idea of the "proper" newsgroup to plop this onto.

i think jacob was reasonably on-topic as can be expected. (at least
you should see how conversations drift at comp.dsp. be careful there
because i have been known to rant if the provocation is sufficient.
and i'm not the only one.)

i gotta find that gnu.gcc.whateve r group and post the question there.

r b-j
r b-j

[robert bristow-johnson]

On Jun 6, 6:11 pm, Erik de Castro Lopo <[e-mail]:

robert bristow-johnson wrote:

i still haven't heard the magic invocation i make to the gcc compiler
that will warn me when an implicit conversion can potentially change a
value. the manual seems to say that -Wconversion should do it, but i
know that it does not, at least in my reasonably current
implementation of gcc on linux.

I haven't tested it, but I think -Wconversion will generate the
warnings you require on things like:

long a ;
int b = 3 ;

a = b ;

why would it do that? there is no loss of information in that
assignment. did you mean b=a;? (then it would have to be established
that sizeof(int)<siz eof(long) or even that would not be a potentially
bad assignment.)

The problem with printf is that is uses <stdarg.hvariab le
parameter passing and hence can't do the same checks.

the conversion that happens when a function is called is another (but
related) issue, and you're right, printf() has no way to know itself
what the size of the args are (except that we inform it with all of
the %d or %hd or %ld) and and my little test program in the original
post demonstrated that with the apparent sign extension done with the
short args. the signed short (a_short_array[26]) was sign extended to
ffff-something when placed on the stack and passed to printf(), but
with the %hx field, only the bottom 16 bits were shown. with the %x
field, it shown the 16 bits of the argument in addition to the 16 bits
of sign extension. either way, when the 32-bit long was assigned to a
16-bit short, this should have generated a warning when -Wconversion
was set, in my opinion. and it didn't.

r b-j