bug in iotc_bsp_io_fs_open

[pnfisher]

iotc_bsp_io_fs_open() in src/bsp/platform/posix/iotc_bsp_io_fs_posix.c, sets resource_handle_out to the FILE * returned by fopen() if fopen() doesn't fail. This in turn gets assigned to the resource manager's context->resource_handle. Later, iotc_resource_manager_read() in src/libiotc/io/fs/iotc_resource_manager.c checks to make sure context->resource_handle is not less the zero.

  if (1 != iotc_handle_disposed(&context->callback) ||
      context->resource_handle < 0) {
    return IOTC_INVALID_PARAMETER;
  }

But there's nothing about fopen() that ensures that the FILE * returned by fopen() can't be a value less than zero (when used in a signed comparison). In fact, on my mediatek mtk8167 arm processor, the value returned by this call to fopen() and then assigned to context->resource_handle is often "negative". For example, here's output from my most recent test run.

xxx iotc_bsp_io_fs_open: line 160, open_flags = 0x1
xxx iotc_bsp_io_fs_open: line 166, fp = 0xb35013c8
xxx iotc_resource_manager_read: line 422
xxx iotc_resource_manager_read: context->resource_handle = 0xb35013c8, -1286597688

This then results in iotc_resource_manager_read() returning an error followed by the iotc library connect() call reporting an inability to read the specified google CA certificate.

I think someone must have originally planned on using open instead of fopen, because only open() calls will guarantee that the values returned upon success are not less than 0.

[MichaelMarkieta]

@pnfisher have you successfully implemented a patch for this? Can you submit a PR for review?

[pnfisher]

I have one for the specific platform (posix) that I'm interested it. Do I have to fill out the corporate CLA first? (If so, I guess I should first make sure my employer is willing to let me submit a PR.)

[pnfisher]

@MichaelMarkieta FYI, better late than never, I've submitted a pull request. #100