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

presently using linux gcc:

$ 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=release --with-system-zlib --enable-__cxa_atexit --
disable-libunwind-exceptions --enable-libgcj-multifile --enable-
languages=c,c++,objc,obj-c++,java,fortran,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)

i run it on this 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 am using this invocation to compile:

$ gcc -Wconversion -o hello hello.c

which results in NO WARNINGS!  even though it is clear that bits are
dropped in this line of code:

  a_short_array[26] = a_ulong;

isn't there a way to get this thing to complain when i do an
assignment (without explicit casting) of a 32-bit int to a 16-bit
int?  we know that bits can be potentially dumped in such an
assignment.  why can't i get this thing to warn me?  i've been to:

http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options

and this seems to confirm what i think the compiler should do.  i have
also tried -Wall .

please reply to both newsgroups as i don't always hang out at
comp.lang.c .

i hope someone can explain this.

thank you.

r b-j
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line.  Sorry.

robert bristow-johnson wrote:
> isn't there a way to get this thing to complain when i do an
> assignment (without explicit casting) of a 32-bit int to a 16-bit
> int?  we know that bits can be potentially dumped in such an
> assignment.  why can't i get this thing to warn me?

That's a job for a tool like "lint".  There are too many legitimate
cases where the potential problem is not an actual problem for the
compiler to routinely warn you about it.  Perhaps in the huge gcc
"manual page" some warning option for this purpose is documented?
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line.  Sorry.

On Jun 8, 10:33 am, "Douglas A. Gwyn" <DAG...@null.net> wrote:
> robert bristow-johnson wrote:
> > isn't there a way to get this thing to complain when i do an
> > assignment (without explicit casting) of a 32-bit int to a 16-bit
> > int?  we know that bits can be potentially dumped in such an
> > assignment.  why can't i get this thing to warn me?
>
> That's a job for a tool like "lint".

actually, i think not.  this is a compiler issue when an implicit type
conversion (between different flavors of int) *may* cause a change of
value.  when building a big project, if you want to impose a
discipline on a bunch of different programmers to not do sloppy
actions that might loose bits somewhere where you won't be looking
(because it is not apparent that any such values were changed in an
expressed equality), these *potential* problems should be flagged in
the build.  then you can go into the code, examine it, and if you
think the conversion is kosher, put an explicit cast on it.  then the
warning goes away.

>  There are too many legitimate
> cases where the potential problem is not an actual problem for the
> compiler to routinely warn you about it.

and for those legitimate cases where you are so confident that the
conversion is no problem, you can use an explicit cast (which
precludes a -Wconversion warning) or you can look at the warning
message at build time, ignore it, and run your code anyway.

>  Perhaps in the huge gcc
> "manual page" some warning option for this purpose is documented?

it is.  and i quoted it.  and it says, with the -Wconversion flag set,
that implicit conversions that *may* change a value get flagged as a
warning.  but in my simple test, it was clear that this conversion
that did just that, did not get even a warning.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line.  Sorry.

"robert bristow-johnson" <rbj@audioimagination.com> wrote...
> On Jun 8, 10:33 am, "Douglas A. Gwyn" <DAG...@null.net> wrote:
>> robert bristow-johnson wrote:
>> > isn't there a way to get this thing to complain when i do an
>> > assignment (without explicit casting) of a 32-bit int to a 16-bit
>> > int?  we know that bits can be potentially dumped in such an
>> > assignment.  why can't i get this thing to warn me?
>> That's a job for a tool like "lint".
> actually, i think not.  this is a compiler issue when an implicit type
> conversion (between different flavors of int) *may* cause a change of
> value.  when building a big project, if you want to impose a
> discipline on a bunch of different programmers to not do sloppy
> actions that might loose bits somewhere where you won't be looking
> (because it is not apparent that any such values were changed in an
> expressed equality), these *potential* problems should be flagged in
> the build.  then you can go into the code, examine it, and if you
> think the conversion is kosher, put an explicit cast on it.  then the
> warning goes away.

So you prefer to make more work for programmers who know
what they are doing, to supposedly protect those who don't?
The point about using a separate tool is that it avoids confusing
compilation with education.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line.  Sorry.

"robert bristow-johnson" <rbj@audioimagination.com> wrote...
> On Jun 8, 10:33 am, "Douglas A. Gwyn" <DAG...@null.net> wrote:
>> robert bristow-johnson wrote:
>> > isn't there a way to get this thing to complain when i do an
>> > assignment (without explicit casting) of a 32-bit int to a 16-bit
>> > int?  we know that bits can be potentially dumped in such an
>> > assignment.  why can't i get this thing to warn me?
>> That's a job for a tool like "lint".
> actually, i think not.  this is a compiler issue when an implicit type
> conversion (between different flavors of int) *may* cause a change of
> value.  when building a big project, if you want to impose a
> discipline on a bunch of different programmers to not do sloppy
> actions that might loose bits somewhere where you won't be looking
> (because it is not apparent that any such values were changed in an
> expressed equality), these *potential* problems should be flagged in
> the build.  then you can go into the code, examine it, and if you
> think the conversion is kosher, put an explicit cast on it.  then the
> warning goes away.

So you prefer to make more work for programmers who know
what they are doing, to supposedly protect those who don't?
The point about using a separate tool is that it avoids confusing
compilation with education.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line.  Sorry.

"robert bristow-johnson" <rbj@audioimagination.com> wrote...
> On Jun 8, 10:33 am, "Douglas A. Gwyn" <DAG...@null.net> wrote:
>> robert bristow-johnson wrote:
>> > isn't there a way to get this thing to complain when i do an
>> > assignment (without explicit casting) of a 32-bit int to a 16-bit
>> > int?  we know that bits can be potentially dumped in such an
>> > assignment.  why can't i get this thing to warn me?
>> That's a job for a tool like "lint".
> actually, i think not.  this is a compiler issue when an implicit type
> conversion (between different flavors of int) *may* cause a change of
> value.  when building a big project, if you want to impose a
> discipline on a bunch of different programmers to not do sloppy
> actions that might loose bits somewhere where you won't be looking
> (because it is not apparent that any such values were changed in an
> expressed equality), these *potential* problems should be flagged in
> the build.  then you can go into the code, examine it, and if you
> think the conversion is kosher, put an explicit cast on it.  then the
> warning goes away.

So you prefer to make more work for programmers who know
what they are doing, to supposedly protect those who don't?
The point about using a separate tool is that it avoids confusing
compilation with education.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line.  Sorry.

"Douglas A. Gwyn" <DAGwyn@null.net> writes:

> "robert bristow-johnson" <rbj@audioimagination.com> wrote...
>> On Jun 8, 10:33 am, "Douglas A. Gwyn" <DAG...@null.net> wrote:
>>> robert bristow-johnson wrote:
>>> > isn't there a way to get this thing to complain when i do an
>>> > assignment (without explicit casting) of a 32-bit int to a 16-bit
>>> > int?  we know that bits can be potentially dumped in such an
>>> > assignment.  why can't i get this thing to warn me?
>>> That's a job for a tool like "lint".
>> actually, i think not.  this is a compiler issue when an implicit type
>> conversion (between different flavors of int) *may* cause a change of
>> value.  when building a big project, if you want to impose a
>> discipline on a bunch of different programmers to not do sloppy
>> actions that might loose bits somewhere where you won't be looking
>> (because it is not apparent that any such values were changed in an
>> expressed equality), these *potential* problems should be flagged in
>> the build.  then you can go into the code, examine it, and if you
>> think the conversion is kosher, put an explicit cast on it.  then the
>> warning goes away.
>
> So you prefer to make more work for programmers who know
> what they are doing, to supposedly protect those who don't?
> The point about using a separate tool is that it avoids confusing
> compilation with education.

If that's your philosophy, then why have any errors or warnings at all?

At what place do you draw the line and say, "This is education, this
is compiling."? 

Even if you "stooped" to placing a warning in such situations, programmers
"who know what they're doing" can still override any warning message by
simply explicitly typecasting.
-- 
%  Randy Yates                  % "Remember the good old 1980's, when 
%% Fuquay-Varina, NC            %  things were so uncomplicated?"
%%% 919-577-9882                % 'Ticket To The Moon' 
%%%% <yates@ieee.org>           % *Time*, Electric Light Orchestra
http://home.earthlink.net/~yatescr
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line.  Sorry.

On Jun 16, 3:12 pm, "Douglas A. Gwyn" <DAG...@null.net> wrote:
> "robert bristow-johnson" <r...@audioimagination.com> wrote...
> > On Jun 8, 10:33 am, "Douglas A. Gwyn" <DAG...@null.net> wrote:
> >> robert bristow-johnson wrote:
> >> > isn't there a way to get this thing to complain when i do an
> >> > assignment (without explicit casting) of a 32-bit int to a 16-bit
> >> > int?  we know that bits can be potentially dumped in such an
> >> > assignment.  why can't i get this thing to warn me?
> >> That's a job for a tool like "lint".
> > actually, i think not.  this is a compiler issue when an implicit type
> > conversion (between different flavors of int) *may* cause a change of
> > value.  when building a big project, if you want to impose a
> > discipline on a bunch of different programmers to not do sloppy
> > actions that might loose bits somewhere where you won't be looking
> > (because it is not apparent that any such values were changed in an
> > expressed equality), these *potential* problems should be flagged in
> > the build.  then you can go into the code, examine it, and if you
> > think the conversion is kosher, put an explicit cast on it.  then the
> > warning goes away.
>
> So you prefer to make more work for programmers who know
> what they are doing, to supposedly protect those who don't?
> The point about using a separate tool is that it avoids confusing
> compilation with education.

first of all, i think it should be an option.  and the way that -
Wconversion was described in the manual i quoted, it appears that this
option actually existed in gcc, and i *know* this option existed (as a
check box) in CodeWarrior on the Mac, when i used it.

the extra word for programmers who know what they are doing is to used
explicit casts:

    a_short = (short)a_long;

or

    a_long = (long)an_unsigned_long;

typing in the explicit cast is not an undue burden to show the
compiler (and other people looking  at your code) that you *mean* to
be making such an assignment that requires such a conversion that a
value might be changed.  that's not a ridiculous requirement.  it's
similar to requiring that all functions defined have prototypes, that
global variables be avoided whenever possible, that sensible naming
conventions and structured and modular programming (as opposed to
spagetti code) be encouraged, that APIs be defined and used.

requiring explicit type casting whenever there is an assignment from
one type to another, at least when such assignment can change a value,
lest an annoying warning is generated, seems hardly a bad thing to
expect from even the good programmers who know what they are doing.

spagetti code, where people play fast and loose with variant types,
use naming "conventions" where every variable is a one or two letter
name, and no comments, that is something that the programmers who know
what they, themselves, are doing but are too lazy to polish up so that
the code successfully communicates to other human readers, all this is
what i want to avoid in the routine case.

r b-j
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line.  Sorry.

On Jun 16, 3:12 pm, "Douglas A. Gwyn" <DAG...@null.net> wrote:
> "robert bristow-johnson" <r...@audioimagination.com> wrote...
> > On Jun 8, 10:33 am, "Douglas A. Gwyn" <DAG...@null.net> wrote:
> >> robert bristow-johnson wrote:
> >> > isn't there a way to get this thing to complain when i do an
> >> > assignment (without explicit casting) of a 32-bit int to a 16-bit
> >> > int?  we know that bits can be potentially dumped in such an
> >> > assignment.  why can't i get this thing to warn me?
> >> That's a job for a tool like "lint".
> > actually, i think not.  this is a compiler issue when an implicit type
> > conversion (between different flavors of int) *may* cause a change of
> > value.  when building a big project, if you want to impose a
> > discipline on a bunch of different programmers to not do sloppy
> > actions that might loose bits somewhere where you won't be looking
> > (because it is not apparent that any such values were changed in an
> > expressed equality), these *potential* problems should be flagged in
> > the build.  then you can go into the code, examine it, and if you
> > think the conversion is kosher, put an explicit cast on it.  then the
> > warning goes away.
>
> So you prefer to make more work for programmers who know
> what they are doing, to supposedly protect those who don't?

i fail to see any traction in that point.  it's an option called -
Wconversion and the default is OFF.  so if these "programmers who know
what they are doing" do not want to make more work for themselves,
they simply opt not to turn that option on.

> The point about using a separate tool is that it avoids confusing
> compilation with education.

no, it's not about education.  i, for one, did not bring that issue
up.  it's a warning at the compiler level that examines the *implicit*
conversions of known fundamental types (like short, long, unsigned
short, unsigned long, etc) (explicit casts are not warned about, we
can then assume that the "programmers .. know what they are doing"
when they say

    a_short = (short)a_long;

it's when they say (using less illustrative variable names)

    a_short = a_long;

or even

    an_unsigned_short = a_short;
or
    a_short = an_unsigned_short;

or even

    an_unsigned_long = a_short;

where there is a possible change in the value in that assignment (even
if the number of bits had INcreased).

pray tell, what is so bad that when someone makes those assignments,
that they (or someone else reviewing their code for potential bugs)
have an option to get an automated warning that there was a potential
loss of information (or changing of value) in such an assignment (or
passing it to a prototyped function)?  i don't get the objection.
what can possibly be wrong with it, particularly if exactly such an
optional warning (-Wconversion) is described in the gcc manual?

curiously,

r b-j
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line.  Sorry.

"robert bristow-johnson" <rbj@audioimagination.com> wrote in message 
news:clcm-20070622-0012@plethora.net...
> pray tell, what is so bad that when someone makes those assignments,
> that they (or someone else reviewing their code for potential bugs)
> have an option to get an automated warning that there was a potential
> loss of information (or changing of value) in such an assignment (or
> passing it to a prototyped function)?

Try it on some large body of actual code.
There are *many* existing *uncast* instances of char <- int and vice versa,
99.9something% of which are safe even though int-to-char "may lose 
information".
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line.  Sorry.