Thread: How to silence integer overflow warning

  1. #16
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    1,039
    Quote Originally Posted by flp1969 View Post
    Even more: The pre-processor "code" below will always result in CHAR_BIT == 8:
    Code:
    #ifndef CHAR_BIT
    #if ~0 << 8
    #define CHAR_BIT 8
    #elif ~0 << 7
    #define CHAR_BIT 7
    #elif ~0 << 6
    #define CHAR_BIT 6
    #elif ~0 << 5
    #define CHAR_BIT 5
    #else
    #define CHAR_BIT 4
    #endif
    #endif
    Because ~0 will be, at least, of "int" type as per ISO 9989 6.4.4.1.5 (and INT_MIN is 15 bits long [plus the sign bit] as in 5.2.4.2.1, pointed by John). So since 'int' is, at least, 16 bits long, ~0 << 8 will always be "true" (not zero).
    Oh really? You might wanna read this article then:
    Word (computer architecture) - Wikipedia

  2. #17
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    27,924
    Quote Originally Posted by awsdert View Post
    Oh really? You might wanna read this article then:
    Word (computer architecture) - Wikipedia
    flp1969 is right: the minimum permitted value of CHAR_BIT is mandated by the C standard (since the earliest edition, I believe) to be 8, and the minimum number of bits in an int or unsigned int can be deduced from the minimum required ranges.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #18
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    1,039
    Quote Originally Posted by laserlight View Post
    flp1969 is right: the minimum permitted value of CHAR_BIT is mandated by the C standard (since the earliest edition, I believe) to be 8, and the minimum number of bits in an int or unsigned int can be deduced from the minimum required ranges.
    You assume that a compiler would follow the C standard to the letter in the scenario that the processor's word size is smaller than needed to support that size, don't forget that char has always been treated as both a byte and the smallest addressable unit on any computer, to support the processor the compiler would most likely drop standards support in favour of natural word size support

  4. #19
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    27,924
    Quote Originally Posted by awsdert View Post
    You assume that a compiler would follow the C standard to the letter in the scenario that the processor's word size is smaller than needed to support that size, don't forget that char has always been treated as both a byte and the smallest addressable unit on any computer, to support the processor the compiler would most likely drop standards support in favour of natural word size support
    Yes, that's a bit of an issue: however, if you look at the Wikipedia article you linked to, you can observe that the latest listed system with a known number of bits in a byte less than 8 was from 1965. It seems rather strange to want to program for a system that predates BCPL.

    EDIT:
    Oh, actually I see two entries from 1971 where the bits per byte was not listed as known, but the word size of 4 bits indicates that it must have been at most 4 bits. That still predates C itself, and then who knows: maybe it was just 2 bits per byte.

    The point here is that if you're trying to program for such legacy systems for which the C standard was not designed to accommodate, then you should know exactly which systems they are. Blindly shooting in the dark like this is pointless: how do you know that your assumptions on how unsigned integer overflow behaves are correct? That's defined in the C standard, which might not apply.
    Last edited by laserlight; 08-05-2020 at 02:14 AM.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #20
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    1,039
    Quote Originally Posted by laserlight View Post
    Yes, that's a bit of an issue: however, if you look at the Wikipedia article you linked to, you can observe that the latest listed system with a known number of bits in a byte less than 8 was from 1965. It seems rather strange to want to program for a system that predates BCPL.

    EDIT:
    Oh, actually I see two entries from 1971 where the bits per byte was not listed as known, but the word size of 4 bits indicates that it must have been at most 4 bits. That still predates C itself, and then who knows: maybe it was just 2 bits per byte.

    The point here is that if you're trying to program for such legacy systems for which the C standard was not designed to accommodate, then you should know exactly which systems they are. Blindly shooting in the dark like this is pointless: how do you know that your assumptions on how unsigned integer overflow behaves are correct? That's defined in the C standard, which might not apply.
    If you take a closer look at those defines you'll notice I already programmed around that (was actually just trying to silence the compiler warnings but it's still suitable for that scenario), as I said previously however I do plan to look for preprocessor macros like __x86__ which would tell me what processor I need to define the limits for, it's just a hack fix is better than no fix in the short term. In the mean time is there any issues you see that can be experienced on current systems?

  6. #21
    Registered User Sir Galahad's Avatar
    Join Date
    Nov 2016
    Location
    The Round Table
    Posts
    174
    Quote Originally Posted by laserlight View Post
    Plus it is still good to bother since 8 is a magic number whose meaning is expressed clearly as CHAR_BIT.
    Fair point. And to be honest, that's exactly why I still use CHAR_BIT anyhow. It's self-documenting.
    The power of null.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Definitive Guide To Integer Overflow.
    By Dren in forum C Programming
    Replies: 4
    Last Post: 11-08-2019, 01:56 PM
  2. Replies: 6
    Last Post: 09-30-2015, 08:49 AM
  3. integer overflow
    By John Connor in forum C Programming
    Replies: 11
    Last Post: 02-11-2008, 05:30 PM
  4. silence warning when assigning pointers
    By eth0 in forum C Programming
    Replies: 5
    Last Post: 10-27-2005, 11:18 AM
  5. how to handle integer overflow in C
    By kate1234 in forum C Programming
    Replies: 8
    Last Post: 04-23-2003, 12:20 PM

Tags for this Thread