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

[Richard Tobin]

In article <87************ @blp.benpfaff.o rg>,
Ben Pfaff <bl*@cs.stanfor d.eduwrote:

>However, the size of a byte is implementation-defined: it may be
larger than one octet (though not smaller).

How big is an octet on ternary machines?

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Richard Tobin]

In article <11************ **********@w5g2 000hsg.googlegr oups.com>,
Oli Charlesworth <ca***@olifilth .co.ukwrote:

printf("size of short = %d, size of ulong = %d\n", sizeof(short),

sizeof(unsigne d long));

>This makes the assumption that sizeof returns an int, when it
often returns something else.

>Perhaps it does, but on any realistic platform, why would this matter
if we're measuring the size of a short and a long?

Because they're passed to a varargs function (printf), which will try
to access them as ints, so if they're in fact bigger than ints -
regardless of their value - things will go horribly wrong.

I don't think there is a simple reliable way to print a size_t in
general, since it could in principle be bigger than unsigned long
long, but in this case using (int)sizeof(sho rt) would work.

-- Richard

--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Randy Yates]

Vladimir Vassilevsky <an************ @hotmail.comwri tes:

glen herrmannsfeldt wrote:

>Randy Yates wrote:
(snip)

>>printf("siz e of short = %d, size of ulong = %d\n", sizeof(short),
sizeof(unsign ed long));

This makes the assumption that sizeof returns an int, when it
often returns something else. Maybe you should also test
sizeof(sizeof( int))==sizeof(i nt)

This also makes the assumption that sizeof() returns size in bytes,
whereas sizeof returns the size in chars.

It is true that sizeof() returns the size in chars. It is also true
that in C, a char is, by definition, a byte.

However, even if you take "byte" to mean "8 bits," my statement was
not incorrect since Robert stated up front that the compiler was for
the i386, and that machine has 8-bit bytes.

I am aware of this "byte" definition since I ran into it on the TI TMS
C54x C compiler, where sizeof(int) = 1, even though an int is 16
bits. That machine's native datapath is 16 bits wide and incapable of
representing a type smaller than 16 bits.
--
% 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

[Randy Yates]

ri*****@cogsci. ed.ac.uk (Richard Tobin) writes:

In article <11************ **********@w5g2 000hsg.googlegr oups.com>,
Oli Charlesworth <ca***@olifilth .co.ukwrote:

>printf("size of short = %d, size of ulong = %d\n", sizeof(short),

sizeof(unsign ed long));

>>This makes the assumption that sizeof returns an int, when it
often returns something else.

>>Perhaps it does, but on any realistic platform, why would this matter
if we're measuring the size of a short and a long?

Because they're passed to a varargs function (printf), which will try
to access them as ints, so if they're in fact bigger than ints -
regardless of their value - things will go horribly wrong.

I don't think there is a simple reliable way to print a size_t in
general, since it could in principle be bigger than unsigned long
long, but in this case using (int)sizeof(sho rt) would work.

That brings up an interesting question: Doesn't this behavior depend
on the machine's endianness?

For example, consider the statement

printf("sizeof( int) = %d", sizeof(int));

and the case in which int is 16 bits and sizeof() returns 32 bits.

Is it true that a little-endian machine will print this correctly,
while a big-endian machine will not?
--
% Randy Yates % "She's sweet on Wagner-I think she'd die for Beethoven.
%% Fuquay-Varina, NC % She love the way Puccini lays down a tune, and
%%% 919-577-9882 % Verdi's always creepin' from her room."
%%%% <ya***@ieee.o rg % "Rockaria", *A New World Record*, ELO
http://home.earthlink.net/~yatescr

[Richard Tobin]

In article <m3************ @ieee.org>, Randy Yates <ya***@ieee.org wrote:

>For example, consider the statement

printf("sizeof( int) = %d", sizeof(int));

and the case in which int is 16 bits and sizeof() returns 32 bits.

Is it true that a little-endian machine will print this correctly,
while a big-endian machine will not?

For a common method of implementation, yes. If you printed two values
the second would print as zero.

But varargs implementations can be more complicated. They could use
separate arrays for arguments of different types, in which case they
would look in completely the wrong place for the argument.

They could also pass some arguments in registers, in which case it
might work regardless of endianness, or always fail.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Richard Heathfield]

Richard Tobin said:

In article <87************ @blp.benpfaff.o rg>,
Ben Pfaff <bl*@cs.stanfor d.eduwrote:

>>However, the size of a byte is implementation-defined: it may be
larger than one octet (though not smaller).

How big is an octet on ternary machines?

The requirement is to be able to represent at least 256 discrete values.
This can be accomplished in six trits, the relevant trit pattern being
100110.

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

[glen herrmannsfeldt]

Ben Pfaff wrote:

glen herrmannsfeldt <ga*@ugcs.calte ch.eduwrites:

>>This makes the assumption that sizeof returns an int, when it
often returns something else.

sizeof's result is never an int, although it can be an unsigned
int.

So I should have said "always" instead of "often"?

-- glen

[glen herrmannsfeldt]

Vladimir Vassilevsky wrote:

(even more snip)

>>printf("siz e of short = %d, size of ulong = %d\n", sizeof(short),
sizeof(unsign ed long));

>This makes the assumption that sizeof returns an int, when it
often returns something else. Maybe you should also test
sizeof(sizeof( int))==sizeof(i nt)

This also makes the assumption that sizeof() returns size in bytes,
whereas sizeof returns the size in chars. Char may be bigger then one byte.

I would say it is the reader of the output that makes that
assumption, not the program. If you write:

printf("sizeof( short) = %d, sizeof(unsigned long) = %d\n",
(int)sizeof(sho rt), (int)sizeof(uns igned long));

then it is more obvious that it is returning the result
of sizeof.

-- glen

[Richard Tobin]

In article <58************ *************** ***@bt.com>,
Richard Heathfield <rj*@see.sig.in validwrote:

>>>However, the size of a byte is implementation-defined: it may be
larger than one octet (though not smaller).

>How big is an octet on ternary machines?

>The requirement is to be able to represent at least 256 discrete values.
This can be accomplished in six trits, the relevant trit pattern being
100110.

What I was getting at was whether the definition of octet should be
taken to be 8 bits, or 8 whatsits (where whatsit = bit, trit, etc).
That is, can a six-trit word be considered to be smaller than an
octet, defeating the claim that a byte may not be smaller than octet?

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[glen herrmannsfeldt]

Randy Yates wrote:

(snip)

>>I don't think there is a simple reliable way to print a size_t in
general, since it could in principle be bigger than unsigned long
long, but in this case using (int)sizeof(sho rt) would work.

As someone else mentioned, %zu has been added to solve the problem.

That brings up an interesting question: Doesn't this behavior depend
on the machine's endianness?

For example, consider the statement

printf("sizeof( int) = %d", sizeof(int));

and the case in which int is 16 bits and sizeof() returns 32 bits.

Is it true that a little-endian machine will print this correctly,
while a big-endian machine will not?

It is reasonably likely that it will, though it is still wrong.
Also, that will only work if you are just printing one of them.

I consider this a disadvantage of little-endian, as it tends to
hide bugs due to type mismatch until it is too late.
Consider also the mistake of printing a 16 bit value with a
format item expecting 32 bits. (or any function expecting
a 32 bit value.) It might work.

-- glen