gdalwarp can crash when reprojecting into an irrelevant SRS

[Even Rouault]

Seen when trying to reproject the following image to EPSG:32630 :

Driver: GTiff/GeoTIFF
Files: world_4326.tif
Size is 625, 625
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]]
Origin = (89.999999999666670,0.000000000333333)
Pixel Size = (0.143999999999977,-0.143999999999977)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (  90.0000000,   0.0000000) ( 90d 0'0.00"E,  0d 0'0.00"N)
Lower Left  (  90.0000000, -90.0000000) ( 90d 0'0.00"E, 90d 0'0.00"S)
Upper Right ( 180.0000000,   0.0000000) (180d 0'0.00"E,  0d 0'0.00"N)
Lower Right ( 180.0000000, -90.0000000) (180d 0'0.00"E, 90d 0'0.00"S)
Center      ( 135.0000000, -45.0000000) (135d 0'0.00"E, 45d 0'0.00"S)
Band 1 Block=625x4 Type=Byte, ColorInterp=Red
Band 2 Block=625x4 Type=Byte, ColorInterp=Green
Band 3 Block=625x4 Type=Byte, ColorInterp=Blue

The transformation from dst coordinates to src coordinates doesn't fail, but produces very big numbers as coordinates and their truncation to int can change their sign (from huge positive to smallest integer e.g.), hence leading to read outside of source array and a segfault.

In that case, nSrcXSize and nSrcYSize were also equal to 0. By digging, I found that #2445 already dealt about that issue. By reviewing the code of GDALWarpKernel::PerformWarp() and the various GWK functions, it appears that they can't do anything in that case because of the "if (iSrcX >= nSrcXSize

iSrcY >= nSrcYSize) continue" test, so it is safe to return immediately at the beginning of PerformWarp(). Will safe processing time and other potential remaining pitfalls.

[Even Rouault]

Fixed in trunk (r17457) and in branches/1.6 (r17458)