fbsplash behaviour change since 1.13.4

[Nuno Lucas]

Bernhard Reutner-Fischer wrote:
> $ git log 7307e06122997f3d5e0108cd1bab4b11a1d5ebdc^..7307e06122997f3d5e0108cd1bab4b11a1d5ebdc miscutils/fbsplash.c
> commit 7307e06122997f3d5e0108cd1bab4b11a1d5ebdc
> Author: Bernhard Reutner-Fischer
> Date:   Wed Feb 18 15:28:43 2009 +0000
> 
>     - bail out if screen resolution does not match PPM dimensions.
>       Previously a 640x480 PPM on an e.g. 720x400 console would just segfault when
>       reading the lines. While this bug should perhaps be fixed to handle such cases
>       properly we just exit gracefully until somebody is willing to take care of it
>       properly.

Looking at the code I don't see how this can be possible, and I tested 
with a 1024x768 ppm on a 800x600 screen.

The read is done of "line_size" bytes, which is the original image width 
* 3, into a buffer allocated with "line_size" bytes, so where is the 
segfault?

The loops are upper limited by min(image height,screen height) and 
min(image width,screen width) so it can't access memory outside the 
framebuffer size (the start address -- "src" -- is recalculated on each 
scanline).

It seems to me this is a false alarm, maybe from a previous version of 
fbsplash where this could happen.

Any commments?


Regards,
~Nuno Lucas