[r8911] Compile failure on macOS due to type narrowing

[THLeaderH]

Hello all simutransers and thank you so much for the simutrans development team.

Today, I tried compiling of r8911 on macOS and received the following error.

Code Select Expand


dataobj/loadsave.cc:494:33: error: non-constant-expression cannot be narrowed from type 'int' to 'char' in
      initializer list [-Wc++11-narrowing]
                char compr[ 4 ] = { 'w', 'b', '0' + clamp( level, 1, 9 ), 0 };
                                              ^~~~~~~~~~~~~~~~~~~~~~~~~~
dataobj/loadsave.cc:494:33: note: insert an explicit cast to silence this issue
                char compr[ 4 ] = { 'w', 'b', '0' + clamp( level, 1, 9 ), 0 };
                                              ^~~~~~~~~~~~~~~~~~~~~~~~~~
                                              static_cast<char>(        )


Changing loadsave.cc:L494 to

Code Select Expand


char compr[ 4 ] = { 'w', 'b', static_cast<char>('0' + clamp( level, 1, 9 )), 0 };

might be a solution.

Considering the fact that github action workflow of macOS successfully compile the current code, this issue can be solved by modifying the compile settings, but I suggest to explicitly cast the int type into char.

[prissi]

This may be an issue with a newer gcc, which emit more and more braindead warnings as errors. If it warns here, it should warn for similar things in countless other places.

Stopping with an error is against the C++ standard, which says that char to int and int to char (as well as with enums) are implicit conversions and must not require casts. It may generate a warning about loss of precision (as MSVC does in many places, but not there). Especially, since the compiler can find out that the value cannot exceed char range even at compile time.

I put a flag into the makefile, assuming all unknown compiler is clang/gcc.

[Dwachs]

Put a cast there in r8915

[Ters]

I get the error with clang, not with GCC. GCC only emits warning, and only if the int value isn't a known constant expression, which apparently is according to the standard.

Ideally, the compiler should be able to reason that the output of clamp can not be greater than 9 or less than 1, since the definition of clamp is known to it. Doesn't work with a combination of std::min and std::max either, so nothing we can do but force the warning to silence one way or the other.