From: David Brown <david@westcontrol.com>
To: Ricardo Telichevesky <ricardo@teli.org>, <gcc-help@gcc.gnu.org>
Subject: Re: Compiler warnings, overflow
Date: Fri, 01 Aug 2014 08:53:00 -0000 [thread overview]
Message-ID: <53DB5595.1030101@westcontrol.com> (raw)
In-Reply-To: <53DA7643.2000004@teli.org>
On 31/07/14 19:00, Ricardo Telichevesky wrote:
> Hi, hope this is the right list.
>
> Here is my code and output, at the bottom of the e-mail. y is "correct",
> w and z obviously have problems - multiplying two 32-bit integers
> "hoping" the result would be correct assigning to 64-bit - I guess it is
> the same problem as double oneThird= 1/3; the result being zero, and
> not 0.3333.
>
> I was wondering if there is any strict warning that would flag the w and
> z assignments below, or the 1/3 above - the whole right hand side is
> evaluated as a 32-bit integer number, and assigned to a 64-bit integer
> or double. Not advocating this should be a default, but turning it on
> would help me detect some flaws in the code. Took me hours to catch a
> similar bug in my code, trying to solve a sparse system that has
> hundreds of millions of variables...
>
> Thanks!
> Ricardo
>
> laplace utils % cat ovr.c
> #include <stdio.h>
> int main()
> {
>
> unsigned int x = 1015625426;
> unsigned int t = sizeof(double);
>
> size_t y = x * sizeof(double);
> size_t w = x << 3;
> size_t z = x * t;
>
> printf("y= %zd w = %zd z = %zd\n", y, w, z);
> }
> laplace utils % gcc -Wall -o ovr ovr.c
> laplace utils % ovr
> y= 8125003408 w = 3830036112 z = 3830036112
>
>
Hi,
As others have said, it's not easy to warn about this sort of thing
since it is perfectly valid C - and many programs rely on the overflow
behaviour of unsigned integers.
But as a stylistic point, you should probably avoid using types like
"unsigned int" and "size_t" when you are concerned about integer sizes -
it is far safer, clearer, and more portable to use the size-specific
types in <stdint.h> such as "uint32_t" and "uint64_t". Of course, you
might want to use typedefs to make things even clearer, or to allow you
to easily change the sizes at a later date. But start from the
<stdint.h> types.
Another point is to remember to enable optimisation. It won't help in
this case, but some warnings work better when optimisation (at least
-O1) is enabled. And of course your code will run far faster.
David
prev parent reply other threads:[~2014-08-01 8:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-31 17:00 Ricardo Telichevesky
2014-07-31 17:12 ` Andrew Haley
2014-07-31 17:53 ` Manuel López-Ibáñez
2014-08-01 8:53 ` David Brown [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53DB5595.1030101@westcontrol.com \
--to=david@westcontrol.com \
--cc=gcc-help@gcc.gnu.org \
--cc=ricardo@teli.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).