Bug 1562066

Note that the same tests fail on armv7hl, so the problem may be related.
see: https://bugzilla.redhat.com/show_bug.cgi?id=1562084

The gts and metar problems seem related.
They all end in the error "no message found in <file>" even though the file used for testing clearly contains data.
While trying to debug the eccodes_t_gts_get test case I could track the issue down to the file eccodes-2.7.0-Source/src/grib_io.c
function read_any_gts, line 893:

   r->read(r->read_data,buffer+already_read,message_size-already_read,&err);

This one returns with error code -1, but I have no idea why.

this issue has been reported upstream at:
https://software.ecmwf.int/issues/browse/SUP-2408

the problem remains after upgrading to eccodes 2.8.0

This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

Well, I've written comments for this on 
https://jira.ecmwf.int/browse/SUP-2408?focusedCommentId=569724&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-569724

But I will put some notes also on this bugzilla ticket.

Now with eccodes 2.4.1, the following 19 tests fail on Linux 32 bit (On Fedora, i686 and armv7hl):

```
         35 - eccodes_t_bufr_ecc-1290 (Failed)
         65 - eccodes_t_bufr_dump_encode_filter (Failed)
         67 - eccodes_t_bufrdc_ref (Failed)
         76 - eccodes_t_bufr_filter_unpack_pack (Failed)
        100 - eccodes_t_bufr_ecc-875 (Failed)
        118 - eccodes_t_gts_get (Failed)
        119 - eccodes_t_gts_ls (Failed)
        120 - eccodes_t_gts_count (Failed)
        121 - eccodes_t_gts_compare (Failed)
        122 - eccodes_t_metar_ls (Failed)
        123 - eccodes_t_metar_get (Failed)
        124 - eccodes_t_metar_dump (Failed)
        125 - eccodes_t_metar_compare (Failed)
        128 - eccodes_t_grib_sh_ieee64 (Failed)
        131 - eccodes_t_grib_lam_bf (Failed)
        153 - eccodes_t_grib_bitsPerValue (Failed)
        162 - eccodes_t_grib_copy (Failed)
        167 - eccodes_t_grib_second_order (Failed)
        193 - eccodes_t_grib_to_netcdf (Failed)
```

I've put proposal fix for the above issues on https://jira.ecmwf.int/browse/SUP-2408 .
The scratch build with my proposal fixes applied is: https://koji.fedoraproject.org/koji/taskinfo?taskID=80359704

For the following comment:

(In reply to Jos de Kloe from comment #2)
> The gts and metar problems seem related.
> They all end in the error "no message found in <file>" even though the file
> used for testing clearly contains data.
> While trying to debug the eccodes_t_gts_get test case I could track the
> issue down to the file eccodes-2.7.0-Source/src/grib_io.c
> function read_any_gts, line 893:
> 
>    r->read(r->read_data,buffer+already_read,message_size-already_read,&err);
> 
> This one returns with error code -1, but I have no idea why.

This is because before the above line, the following is executed:

    r->seek(r->read_data, already_read - message_size);

Here "already_read" and "message_size" are both size_t, and the above r->seek
(actually stdio_seek) second arguments accepts off_t value. Note that
here "already_read" is *smaller* than message_size.

On 64 bit, size_t is 64bit unsigned, off_t is 64bit signed. So when the
above "already_read - message_size" is once calculated on 64bit unsigned "huge" value
and then passed to "stdio_seek" second argument, it is again converted
to signed negative value, this is intended (i.e. there r->seek is intended
to seek toward the head of the file).

But on 32 bit, size_t is 32bit unsigned, but off_t is 64 bit signed because
compilation flags specify "-D_FILE_OFFSET_BITS=64". so the above
"already_read - message_size" is once calculated as 32 bit unsigned "huge" value,
then converted to 64 bit signed value - but on this case this 32 bit
unsigned "huge" value does not change (to intended negative value).
So r->seek (actually stdio_seek) accepts invalid huge positive value, and the following
r->read fails.

Well, actually 2.24.1, not 2.4.1...

Upstream has now decided that "No more work will be done from our side for 32-bit platforms.".
See: https://jira.ecmwf.int/browse/SUP-2408

So I propose to close this issue.