robert bristow-johnson

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/Wa...arning-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.

douglas a. gwyn

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.

willerz

That's the manual for the current version of gcc; yours is older. The
gcc manual on my Mac (4.0.1 era) says that -Wconversion only applies to
conversions done as a result of the existence of a function prototype.
I suspect the same is true of your version. You can of course check by
running "info gcc" then entering "/-Wconversion" to get to the relevant
section.
--
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

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.


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.

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.

douglas a. gwyn

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.

oli charlesworth

If the programmers knew what they were doing, they'd know that writing
good code in a team environment involves making it self-documenting.
Use of explicit casts, semantics such as "static" and "const", and not
relying on platform-dependent quirks are a few ways of achieving this
goal.

Although a lot of programmers think it's terribly clever to be able to
hold all the subtle gotchas about their code in their head, or make
liberal use of language quirks (I used to be one of these people),
it's not terribly productive when more than one person (themself) has
to read their code.

There's also the fact that "knows what they're doing" != "infallible".
If there's no explicit cast, there's no way of telling whether it was
intentional, or an oversight that will only display faulty behaviour
in edge cases.


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

randy yates

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

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.

robert bristow-johnson

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.

brooks moses

(posted and emailed)

If the compiler is not behaving according to its documentation, that's a
bug. Speaking as a GCC developer, my advice is to make sure that you're
using the most recent version, and then please file a bug report so
either the code or documentation can be fixed.

- Brooks


--
The "bmoses-nospam" address is valid; no unmunging needed.
--
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

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.

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.