Thread: [Lcms-user] Build warnings on OSX / clang
An ICC-based CMM for color management
Brought to you by:
mm2
From: Aaron B. <bo...@gm...> - 2017-07-24 01:16:09
|
Hello, Just wanted to report a few warnings I am getting when building with clang. http://my.cdash.org/viewBuildError.php?type=1&buildid=1257347 For example: <a href='https://github.com/GrokImageCompression/grok/blob/master/grok/thirdparty/liblcms2/src/cmsgamma.c#L143'>grok/thirdparty/liblcms2/src/cmsgamma.c:143</a>:32: warning: implicit conversion changes signedness: 'cmsUInt32Number' (aka 'unsigned int') to 'int' [-Wsign-conversion] fl ->nFunctions = Plugin ->nFunctions; ~ ~~~~~~~~~^~~~~~~~~~ <a href='https://github.com/GrokImageCompression/grok/blob/master/grok/thirdparty/liblcms2/src/cmsgamma.c#L150'>grok/thirdparty/liblcms2/src/cmsgamma.c:150</a>:63: warning: implicit conversion changes signedness: 'int' to 'unsigned long' [-Wsign-conversion] memmove(fl->FunctionTypes, Plugin ->FunctionTypes, fl->nFunctions * sizeof(cmsUInt32Number)); Thanks, Aaron |
From: Martí M. <mar...@li...> - 2017-07-24 07:24:11
|
Thanks for reporting. lcms uses the C feature of implicit sign conversion, so if you activate -Wsign-conversion you will get some warnings. This not set in the included build system. Regards Marti On 7/24/2017 3:16 AM, Aaron Boxer wrote: > Hello, > Just wanted to report a few warnings I am getting when building with > clang. > > http://my.cdash.org/viewBuildError.php?type=1&buildid=1257347 > > For example: > > <a href='https://github.com/GrokImageCompression/grok/blob/master/grok/thirdparty/liblcms2/src/cmsgamma.c#L143'>grok/thirdparty/liblcms2/src/cmsgamma.c:143</a>:32: warning: implicit conversion changes signedness: 'cmsUInt32Number' (aka 'unsigned int') to 'int' [-Wsign-conversion] > fl ->nFunctions = Plugin ->nFunctions; > ~ ~~~~~~~~~^~~~~~~~~~ > <a href='https://github.com/GrokImageCompression/grok/blob/master/grok/thirdparty/liblcms2/src/cmsgamma.c#L150'>grok/thirdparty/liblcms2/src/cmsgamma.c:150</a>:63: warning: implicit conversion changes signedness: 'int' to 'unsigned long' [-Wsign-conversion] > memmove(fl->FunctionTypes, Plugin ->FunctionTypes, fl->nFunctions * sizeof(cmsUInt32Number)); > > Thanks, > Aaron > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > Lcms-user mailing list > Lcm...@li... > https://lists.sourceforge.net/lists/listinfo/lcms-user |
From: Aaron B. <bo...@gm...> - 2017-07-24 12:20:49
|
Hi Marti, Thanks. I've turned on this warning in my build because the implicit conversion can cause hard-to-trace bugs. Regards, Aaron On Mon, Jul 24, 2017 at 3:10 AM, Martí Maria <mar...@li...> wrote: > > Thanks for reporting. > > lcms uses the C feature of implicit sign conversion, so if you activate > -Wsign-conversion you will get some warnings. > > This not set in the included build system. > > Regards > > Marti > > On 7/24/2017 3:16 AM, Aaron Boxer wrote: > > Hello, > Just wanted to report a few warnings I am getting when building with clang. > > http://my.cdash.org/viewBuildError.php?type=1&buildid=1257347 > > For example: > > <a href='https://github.com/GrokImageCompression/grok/blob/master/grok/thirdparty/liblcms2/src/cmsgamma.c#L143'>grok/thirdparty/liblcms2/src/cmsgamma.c:143</a>:32: warning: implicit conversion changes signedness: 'cmsUInt32Number' (aka 'unsigned int') to 'int' [-Wsign-conversion] > fl ->nFunctions = Plugin ->nFunctions; > ~ ~~~~~~~~~^~~~~~~~~~ > <a href='https://github.com/GrokImageCompression/grok/blob/master/grok/thirdparty/liblcms2/src/cmsgamma.c#L150'>grok/thirdparty/liblcms2/src/cmsgamma.c:150</a>:63: warning: implicit conversion changes signedness: 'int' to 'unsigned long' [-Wsign-conversion] > memmove(fl->FunctionTypes, Plugin ->FunctionTypes, fl->nFunctions * sizeof(cmsUInt32Number)); > > > Thanks, > > Aaron > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > Lcms-user mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/lcms-user > > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Lcms-user mailing list > Lcm...@li... > https://lists.sourceforge.net/lists/listinfo/lcms-user > > |
From: Bob F. <bfr...@si...> - 2017-07-24 16:38:58
|
On Mon, 24 Jul 2017, Aaron Boxer wrote: > Hi Marti, > > Thanks. I've turned on this warning in my build because the implicit > conversion can cause > hard-to-trace bugs. Inappropriate explicit casts in the C code can also cause hard-to-trace bugs and explicit casts should be minimized. I think that usually implicit type conversion should be preferred over many explicit casts. Regardless, type conversion should be minimized as much as possible. Not all compiler warnings are intended to be enabled for normal use. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: Aaron B. <bo...@gm...> - 2017-07-24 17:43:52
|
> Thanks. I've turned on this warning in my build because the implicit >> conversion can cause >> hard-to-trace bugs. >> > > Inappropriate explicit casts in the C code can also cause hard-to-trace > bugs and explicit casts should be minimized. I think that usually implicit > type conversion should be preferred over many explicit casts. Regardless, > type conversion should be minimized as much as possible. > Absolutely agree - casts are a necessary evil :) > > Not all compiler warnings are intended to be enabled for normal use. > > Yes, I suppose I could disable the warning for production. Aaron |
From: Noel C. <NCa...@Pr...> - 2017-07-24 20:49:00
|
Hello all, Compiler warnings are available to show us where programmers have taken liberties with the language, but have not acknowledged those liberties (via a cast). IMO, the C language implicit integer assignment rules were a shortcoming of the language, leading to sloppy work, not a feature. In our projects all our code builds clean with Visual Studio's max warning level (-Wall) and Code Analysis. We don't allow warnings to persist, and I honestly don't know why - other than economics - anyone would want to set a project up to use anything less. I don't mean to be critical of Marti's code - it's very good overall and emits no warnings with Visual Studio 2017 on level 4 (which is better than most source projects), but it DOES gather hundreds of warnings when set to -Wall, many of which are of the form: ..\..\..\src\cmsgamma.c(143): warning C4365: '=': conversion from 'cmsUInt32Number' to 'int', signed/unsigned mismatch Unfortunately, it really IS a coding error to expect an unsigned integer to fit implicitly into a signed integer. If you "just know" that there can be no sign problems, then the code should reflect that. The right solution is not to add casts, but rather to change the code so that the data types DO match one another - or in a pinch use explicit casts in the code (with appropriate comments) indicating that the disparity has been noted and is expected and okay. In the specific case identified (an unsigned 32 bit number being copied to a signed 32 bit value) we can't know, without careful analysis of the code, whether there can be (now, or in the future) a negative number or positive 32 bit number larger than 2^31 passed around. That's a gotcha that should not be left in. If types have to change, of course it's necessary to work out the problems each code change could cause. That's the cost of creating truly good code. The upside is that when it's done the code can be consistently compiled with the highest warning level, which helps keep errors from creeping in during ongoing development. Marti, I'm willing to take a look at reducing the warning count if you're willing to entertain putting the changes back into your sources (as you have done in the past). -Noel Carboni ProDigital Software |