Skip to content

FIO_CreateFile and FIO_OpenFile should return 0 on error, just like in plain C

Alex requested to merge branch/fio_create_return_0 into branch/unified

The problem: Canon's FIO routines return -1 on error, unlike fopen from plain C, which returns 0.

We are often tempted to check whether the file handle is 0 or not, and this mistake gets overlooked. I've found a bunch of such mistakes with QEMU, but even if I fix everything now, I'm sure it will still happen in the future if we don't take action.

Proposed solution: the FIO wrappers from fio-ml.c should behave just like fopen (return 0 on error). So, even if we are writing code for desktop PCs, or for the camera, file error checking should be the same.

This change is potentially disruptive, and may cause problems in experimental modules that are not in the unified branch. We may want to bump the version number in module API to prevent binary incompatibilities.

To prevent source mistakes (that is, you should not be able to just recompile your module without fixing it), I've renamed INVALID_PTR to PTR_INVALID. This forces you to review each usage of this macro, and if it's for FIO error checking, you will know to use 0 instead, and if it's not FIO-related, you should just rename it.

Still not covered: checks like if (f == (void*) -1) will not be flagged as mistakes by the compiler.

Potential issue: DryOS might return 0 as valid file handle. Could this ever happen?

Merge request reports