#52 Out-of-bounds access in pfsview_widget

[Stefan Brüns]

GCC 11.2.1 rightfully complains:
https://sourceforge.net/p/pfstools/git/ci/master/tree/src/pfsview/pfsview_widget.cpp#l355

[   64s] /home/abuild/rpmbuild/BUILD/pfstools-2.2.0/src/pfsview/pfsview_widget.cpp:357:28: warning: iteration 256 invokes undefined behavior [-Waggressive-loop-optimizations]
[   64s]   357 |       lutPixFloor[257+p+1] = getInverseMapping( mappingMethod, p_left, minValue, maxValue );
[   64s]       |                            ^
[   64s] /home/abuild/rpmbuild/BUILD/pfstools-2.2.0/src/pfsview/pfsview_widget.cpp:355:23: note: within this loop
[   64s]   355 |     for( int p = 0; p < 257; p++ ) {

float lutPixFloor[257*2];

i.e. for p==256 the code accesses lutPixFloor[257+256+1], which is lutPixFloor[257*2], but the last valid index is `257*2-1

[Stefan Brüns]

https://sourceforge.net/p/pfstools/git/ci/master/tree/src/pfsview/pfsview_widget.cpp#l492

        int p = binarySearchPixels( (*R)(index), lutPixFloor, lutSize );     
        pixel = lutPixel[p];
         if( infNaNTreatment == INFNAN_MARK_AS_RED && (p == 0 || p == LUTSIZE+1)) 

As p converges to lutSize - 1 for large values, and lutSize = 257 * 2 + 1;, this is also an OOB access.

So apparently float lutPixFloor[257 * 2 + 1] is correct.

Also, p == LUTSIZE + 1 here (L494) should probably read p == lutSize - 1.

[Rafal Mantiuk]

Thank you for reporting those.

Yes, the LUT had the wrong size and you are right about the condition in L496. This is a very old code so I was not sure why the condition was there in the first place.

This should be fixed now.