Thanks to Noel for offering fixes, and to Marti for graciously accepting :)

I've gone through similar issues with my JPEG 2000 codec, much of the code
inherited from developers
who didn't worry about these issues.  I spent a lot of time converting
signed to unsigned for all quantities
that must always be positive : number of image components, image
dimensions, etc.
Also, removed as many casts as possible. The code is now more resilient to
overflow, and compiles with no
warnings at maximum -Wall compiler settings. I think it is worth the effort.

Regards,
Aaron






On Mon, Jul 24, 2017 at 6:31 PM, Marti Maria <marti.ma...@littlecms.com>
wrote:

> Sounds great. All improvements are more than welcome.
> Regards
> Marti
>
> On 25 Jul 2017 00:27, Noel Carboni <ncarb...@prodigitalsoftware.com>
> wrote:
>
> Hi Marti,
>
>
>
> As C/C++ programmers we have to face the fact that the language is growing
> ever more tightly typed.
>
>
>
> It's not quite correct even to promote implicitly from signed to unsigned
> when you "just know" that the values will be small, since under some
> conditions negative numbers could have meaning.  Or worse, be given special
> meaning in the future.  It's tempting to return -1 as a special error or
> "not found" case, but that can ultimately cause conflict with code that
> expects only signed values.
>
>
>
> It's only really properly done - and thus "safe" from future maintenance
> problems - if you use consistent types across the board, or add casts
> occasionally when you really do want to express that you're fitting a small
> positive unsigned value into a signed field.
>
>
>
> Looking your released code over just now I think that it can be
> substantially cleaned up without a lot of casts added.  There are a lot of
> cases where you have a habit of using "int" when what you really want is
> "unsigned int" (e.g., for number of channels, where negative values don't
> have meaning).  :)
>
>
>
> Tell you what; I'll go through all the code and see what I can come up
> with to get it down to zero warnings at max warning level.  I don't think
> it'll take me more than a few man-hours.  I'll send the result to you and
> you can compare the files and see whether you feel the changes are safe
> enough.  I'll make it my mission not to change the logic or your intent
> with the style.
>
>
>
> -Noel
>
>
>
> *From:* Marti Maria [mailto:marti.ma...@littlecms.com]
> *Sent:* Mon, July 24, 2017 6:09 PM
> *To:* Noel Carboni
> *Cc:* lcms-user@lists.sourceforge.net
> *Subject:* Re: [Lcms-user] Build warnings on OSX / clang
>
>
>
> Hi,
>
>
>
> Sometimes I use  signed to unsigned promotion without cast. This is safe
>  if values are small and positive. Mostly to avoid casts in memset,
> memmove, calloc, etc. which looks really ugly.
>
>
>
> If you can found other cases, like that one in cmsgamma.c, please let me
> know. But this latter was fixed after the original report.
>
>
>
> Regards
>
> Marti
>
>
>
> ------------------------------------------------------------
> ------------------
> 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
> Lcms-user@lists.sourceforge.net
> 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
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Reply via email to