From Gentoo's build process I got : * QA Notice: Package may compile * fine but exhibit random runtime failures. * ./base/gdevpdfc.c:433:24: warning: array subscript is above array bounds [-Warray-bounds] * ./base/gdevpdfc.c:433:24: warning: array subscript is above array bounds [-Warray-bounds] * ./base/gdevpdfc.c:433:24: warning: array subscript is above array bounds [-Warray-bounds] * ./base/gdevpdfc.c:433:24: warning: array subscript is above array bounds [-Warray-bounds] * Please do not file a Gentoo bug and instead report the above QA * issues directly to the upstream developers of this software. * Homepage: http://ghostscript.com/
With no job to illustrate warning, we can't really help.
(In reply to comment #1) > With no job to illustrate warning, we can't really help. It claims to be a compile-time warning. However I cannot see what it is complaining about, the local array is declared as size 3 and the subscripts are 0 to 2. The parameters to the function are pointers, and their size is not given, so there is no way for the compiler to know if the subscripts indexing those arrays are out of bounds (they are not). So this looks like a bogus static analysis warning from the compiler.
(In reply to comment #2) > (In reply to comment #1) > > With no job to illustrate warning, we can't really help. > > It claims to be a compile-time warning. However I cannot see what it is > complaining about, the local array is declared as size 3 and the subscripts are > 0 to 2. The parameters to the function are pointers, and their size is not > given, so there is no way for the compiler to know if the subscripts indexing > those arrays are out of bounds (they are not). > > So this looks like a bogus static analysis warning from the compiler. Actually, on second thought, one of those indexes just *might* be wrong.
(In reply to comment #3) > Actually, on second thought, one of those indexes just *might* be wrong. Its a static function, and its only called in two places (one routine), lines 535 and 541. Indeed the arrays being passed in are of size 4, and the code is definitely accessing array[4] which is absolutely off the end of that array. RGB[0] = in[0] + in[4]; should obviously be: RGB[0] = in[0] + in[3]; I'll fix it and test, it must be an obscure code path though.
Oops, sorry. But, as "in" is declared as a pointer, rather than an array, I'm a bit bemused as to how static analysis can judge that the index is out-of-bounds.
(In reply to comment #5) > Oops, sorry. > > But, as "in" is declared as a pointer, rather than an array, I'm a bit bemused > as to how static analysis can judge that the index is out-of-bounds. Presumably because its a static function, so the compiler only has to trace the calls in this module, of which there are 2, both using arrays of size 4. The only way to exercise this code is to have pdfwrite produce a PDF/A or PDF/X file, where the ProcessColorModel is set to DeviceRGB but we have an input /Separation or /DeviceN colour space with a DeviceCMYK /Alternate. So really quite obscure and won't be tested by the regression suite, which is why this has never cropped up before.
Fixed in commit: 13028e7b90dba007183c4b64a5d6b1363e30c993 I believe this is fixed but, obviously, my compiler doesn't complain about this issue so it would be very helpful if the original reporter could test this change.
(In reply to comment #7) > I believe this is fixed but, obviously, my compiler doesn't complain about this > issue so it would be very helpful if the original reporter could test this > change. I cherry-picked that commit and applied it to the GentooÄs package - issue went away ;-) FWIW however the issue happens only when I compiled ghostscript within a chrooted environment for my user mode linux image. Compiling the same package at the host systems was fine even before. The only difference in the compiler command line is -DHAVE_DBUS which is not set within my UML image. OTOH the configure step itself might show much more differences.
(In reply to comment #8) > > issue so it would be very helpful if the original reporter could test this > > change. > I cherry-picked that commit and applied it to the GentooÄs package - issue went > away ;-) I'll take that as a fix then, thanks for testing it ! > FWIW however the issue happens only when I compiled ghostscript within a > chrooted environment for my user mode linux image. Compiling the same package > at the host systems was fine even before. I'm not enough of a Linux expert to have a useful opinion. However, the code was clearly wrong as it stood, so I'm happy to have changed it. Thanks for your report.
(In reply to comment #7) > my compiler doesn't complain about this issue It is gcc 4.6.1 which complained about it, 4.4.5 did not complain about it. Another possible answer is, that the package compiled w/ 4.6.1 is configured in a slightly different way (--without-x --disable-dbus --disable-gtk) than the package which was compiled w/ 4.4.5.