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

[Erik de Castro Lopo]

robert bristow-johnson wrote:

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

When using gcc, I usually use -Wall -Wextra -Werror which turns
on all warnings and makes all warnings into errors.

Not sure if this will help in your case.

Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"There are only two things wrong with C++: The initial concept and
the implementation. " -- Bertrand Meyer

[Keith Thompson]

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

Richard Heathfield wrote:

>Richard Tobin said:

(snip)

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

>The C Standard makes no such claim. It only makes the claim that a byte
must be at least 8 bits wide. If we accept the possibility of a ternary
machine, the minimum number of trits that would do the trick is 6.

C sort of expects a binary representation. Unsigned addition is
module some power of two, and bitwise operators would be very slow
otherwise.

C99 explicitly requires a binary representation. (Emulating binary on
a ternary machine would be valid.)

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

[Randy Yates]

Richard Heathfield <rj*@see.sig.in validwrites:

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.

Wouldn't a "ternary digit" be a "tit"??? "How many tits are in that byte?"...
--
% Randy Yates % "And all that I can do
%% Fuquay-Varina, NC % is say I'm sorry,
%%% 919-577-9882 % that's the way it goes..."
%%%% <ya***@ieee.o rg % Getting To The Point', *Balance of Power*, ELO
http://home.earthlink.net/~yatescr

[Keith Thompson]

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

i just wanna know what flag to set (if any) that makes the
compiler tell me i might want to check the statement that could
potentially throw away those bits. i would think, from the
description that -Wconversion or -Wall should do it, but it doesn't
and i was wondering if the hardcore C or gcc geeks might know the
magic invocation to generate such a warning.

[...]

Try gnu.gcc.help.

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

[Jerry Avins]

Keith Thompson wrote:

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

>glen herrmannsfeldt wrote:

>>Randy Yates wrote:
(snip)

printf("si ze of short = %d, size of ulong = %d\n", sizeof(short),
sizeof(unsig ned 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( int)

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.

No, a "byte" is by definition the size of a char. The term "byte" may
have other meanings outside the context of C, but sizeof(char) is 1 by
definition.

Isn't a byte in C the larger of character, octet, or smallest
addressable storage element?

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

[Randy Yates]

Erik de Castro Lopo <er***@mega-nerd.comwrites:

robert bristow-johnson wrote:

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

When using gcc, I usually use -Wall -Wextra -Werror which turns
on all warnings and makes all warnings into errors.

Not sure if this will help in your case.

It doesn't on my machine.

[yates@localhost tmp]$ gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure
Thread model: posix
gcc version 4.1.2
--
% Randy Yates % "And all that I can do
%% Fuquay-Varina, NC % is say I'm sorry,
%%% 919-577-9882 % that's the way it goes..."
%%%% <ya***@ieee.o rg % Getting To The Point', *Balance of Power*, ELO
http://home.earthlink.net/~yatescr

[Richard Heathfield]

Jerry Avins said:

Keith Thompson wrote:

<snip>

>No, a "byte" is by definition the size of a char. The term "byte"
may have other meanings outside the context of C, but sizeof(char) is
1 by definition.

Isn't a byte in C the larger of character, octet, or smallest
addressable storage element?

Well, that isn't how it's defined! But yes, your rule looks correct to
me. I think it's easier to think of it as 8+ bits wide.

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

[Richard Tobin]

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:

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

>Correction: things *might* go horribly wrong. Worse, they might go
horribly right.

Going horribly right is just one of the ways it might go horribly wrong.

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

[robert bristow-johnson]

On Jun 5, 8:06 pm, Richard Heathfield <[e-mail].i nvalidwrote:

robert bristow-johnson said:

isn't it clear that when i run these lines of code:

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 );

and get this for output:

256, d687, ffffd687, 12d687

that the bits in the hex digits "12" went bye-bye in the assignment
statement?

Yes. the C Standard does not require implementations to produce a
diagnostic message in this circumstance. A conversion is supplied. Of
necessity, if the lvalue is less wide than the rvalue, any information
stored in those extra bits will be lost. Nevertheless, the conversion
is a useful one in situations where no information is lost, and to take
advantage of it does not constitute a syntax error or constraint
violation, so no diagnostic message is required.

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 (maybe it does, but it should
also do it for the original example i brought).

so i can see this warning as being functionally different from one of
type checking or even if there is a bit reduction. i just wish it
worked right.

>

i just wanna know what flag to set (if any) that makes the
compiler tell me i might want to check the statement that could
potentially throw away those bits.

Check in a newsgroup that deals with your implementation.

yeah, i should look for a gnu or gcc newgroup. just dunno where.

r b-j

[robert bristow-johnson]

On Jun 5, 8:13 pm, Keith Thompson <[e-mail] ote:

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

[...] i just wanna know what flag to set (if any) that makes the

compiler tell me i might want to check the statement that could
potentially throw away those bits. i would think, from the
description that -Wconversion or -Wall should do it, but it doesn't
and i was wondering if the hardcore C or gcc geeks might know the
magic invocation to generate such a warning.

[...]

Try gnu.gcc.help.

thanks. didn't even know about the gnu hierarchy.

r b-j