Re: [Lcms-user] One More Possible Important Compiler Warning

[Phil R. <phi...@or...>]

Since there has been a fair amount of changes recently which might
be compiler sensitive, I pulled the trunk just now (well 2 hours ago) 
and tried out
building OpenJDK 7, 8 and 9 with those bits using the JDK "offical"
compilers used to build each of those releases on Windows, Mac,
Linux (various versions), and Solaris. I had just one new build warning
that I noticed (but we do suppress a few) related to a usage in the
change in the return type of cmsReadRawTag from signed int to unsigned int :

jdk/src/java.desktop/share/native/liblcms/LCMS.c: In function 
'_writeCookedTag':

jdk/src/java.desktop/share/native/liblcms/LCMS.c:853:29: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
                  if (tagSize ==  cmsReadRawTag(pfTarget, s, buf, tagSize)) {


So no problem compiling the LCMS code itself. Just the one small
change needed in our code that calls into it.

We don't (yet) use VS2017 for compiling JDK on Windows, but it
seems that is being verified already by Noel, so far, so good.

-phil.

On 08/24/2017 09:24 AM, Martí Maria wrote:
>
>
> Thanks Noel, I have incorporated your changes in the main trunk. But 
> don't worry too much, this function is not used by the rest of the 
> library as it is kept here for compatibility with old apps.
>
> Thanks again
>
> Marti
>
>
> On 8/9/2017 8:34 PM, Noel Carboni wrote:
>>
>> Hi Marti,
>>
>> By the way, there is one more possibly important warning you should 
>> think about addressing for release 2.9, this time issued from the VS 
>> 2017 Code Analyzer:
>>
>> *c:\dev\prodigital\trunk\libraries\littlecms\src\cmsgamma.c(1153): 
>> warning C6262: Function uses '49196' bytes of stack: exceeds 
>> /analyze:stacksize '16384'.  Consider moving some data to heap.*
>>
>> This is because of the following code, in cmsgamma.c:
>>
>> // Maxim number of nodes
>>
>> #define MAX_NODES_IN_CURVE   4097
>>
>> ...
>>
>> // Smooths a curve sampled at regular intervals.
>>
>> cmsBool CMSEXPORT cmsSmoothToneCurve(cmsToneCurve* Tab, 
>> cmsFloat64Number lambda)
>>
>> {
>>
>> cmsFloat32Number w[MAX_NODES_IN_CURVE], y[MAX_NODES_IN_CURVE], 
>> z[MAX_NODES_IN_CURVE];
>>
>> The w, y, and z arrays are a bit on the large size for stack 
>> variables.  I did some reading on Windows stack allocations and the 
>> stack may be quite limited under some conditions.  It's possible the 
>> same applies to other architectures too.
>>
>> I recommend considering changing the code to malloc several temporary 
>> buffers instead of allocating blocks of stack space.  Here's a 
>> suggested implementation using _cmsCalloc / _cmsFree, and which is 
>> more structured and now properly reports all errors.  It passes all 
>> tests and performance is good, per the testbed, though I recommend a 
>> very careful review.  Both the current Github code and proposed new 
>> code blocks are in this file.  Compile the new code for comparative 
>> testing by defining the symbol PRODIGITAL_OPTIMIZATIONS, which can 
>> also be used to find the changes in the source.
>>
>> http://Noel.ProDigitalSoftware.com/temp/cmsgamma_proposed_changes.zip
>>
>> Please let me know if you have questions.
>>
>> -Noel
>>
>
>
>
> ------------------------------------------------------------------------------
> 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