public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
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



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