weird Norcroft behaviour when using max value for a uint32_t

when returning a max value for a uint32_t (4294967295) norcroft rises a warning:

implicit narrowing cast: `return`

the same code using 0xFFFFFFFF instead (which obviously is the Hexadecimal for 4294967295) rise no warning and works fine.

There shouldn’t be a warning for the decimal notation.

Not a biggie, but worth tracking I think.

My understanding is that compiler bugs should be reported via the ‘tools’ email address to ensure that they’re seen.

Edit: And then, having seen the posts below, I’m now glad that it was posted here and could have discussion :)

Did you try “4294967295U” to make it unsigned?

Or even UINT32_MAX ! Such large decimal values without U suffix are likely to be treated as ll values these days, hence the narrowing.

@ Jeff

obviously with `u` works, however on all other compilers tested (gcc, clang, MVC etc.) `u` is not required.

@ Stuart

I am pretty sure that UNIT32_MAX is defined using 0xFFFFFFFF instead of the decimal form ;)

http://port70.net/~nsz/c/c11/n1570.html#6.4.4.1p5

And note that hex values are treated slightly differently to decimal values.

Whether or not it’s needed, I suppose, depends upon how the compiler “sees” the code. Perhaps one compiler notices that the value is being assigned to an unsigned and treats it as unsigned while the other treats it as signed unless you add the ‘u’ to specify otherwise?
I’m with Norcroft here – I don’t like things that make assumptions.

Or, on the other hand, maybe it’s just a warning that is usually turned off?

[Edit: ‘gub in Norcroft’ Ha. I was wrong. It does appear that it is Norcroft that’s the standards-compliant one here!]

For a laugh, try -c89 though – 4294967295 is clearly shown (by an extra warning!) as being treated as unsigned long (which is ‘wider’ than unsigned int even though they have the same representation here – when I took over PipeDream development for RISC OS at Colton Software there were literally hundreds of these ‘helpful’ warnings to sort out as it liberally used long, coming from PC where int was short).

C99 onward should never* treat unsuffixed decimal integer constants as unsigned, so 4294967295 is going to be a long long int on 32-bit ARM Norcroft C, and actually wider than unsigned int (I have assumed that is the return type of your function, Paolo, or uint32_t – it’s what I am using to test with).

[Edit #2: * For those who don’t have the C99 ISO standard, any decimal integer constant without a suffix should be mapped into the smallest possible type that fits it from the list: int, long int, long long int (NB none of which are unsigned), whereas for C89 it was int, long int, unsigned long int.]

Or, on the other hand, maybe it’s just a warning that is usually turned off?

So, on GCC, CLang, MVC I am using my default “config” which is “enable every possible warning and treat them as errors”, gcc example for clarity:

-std=c99 -Wpedantic -Wall -Wextra -Werror

So, AFAICT, it’s like Stuart said, it’s strictly a “gub in Norcroft” (and I am using slang too now! lol)

@ Stuart

Ha. I was wrong. It does appear that it is Norcroft that’s the standards-compliant one here!

Ok, then it’s the only one compliant so far. Will try IBM old C compiler this evening and a bunch of others, so far none has produced that warning (or a similar one related to the same issue).

@ Stuart

Sure, this is my simple test code, nothing fancy at all:

#include <assert.h>
#include <stdint.h>
#include <stdio.h>

//# define BIG_NUM 0xFFFFFFFF
//# define BIG_NUM 4294967295u
#define BIG_NUM 4294967295

uint32_t big_val(void)
{
    return BIG_NUM;
}

int main(void)
{
  uint32_t test = big_val();

  printf("big num: %u", test);

  assert(test == 0xFFFFFFFF);

  return 0;
}

Side note: I started to write some tests for the compiler after I had Norcroft crashing while compiling some very simple library.

So it doesn’t complain about 0xFFFFFFFF anymore?
I remember a long time ago when starting to maintain the MP3mod code, I had to define the macro I(x) (int)(x)
and use it to encapsulate the hex constants in table has otherwise it was issuing warnings for each hex value above 0×7FFFFFFF.

So it doesn’t complain about 0xFFFFFFFF anymore

Not if you’re using C99 or newer option for compiling – so everything we wrote back in the day would have needed suffixes and associated grumbles.