Standard library/filesystem functions with NULL arguments

[aamcampbell]

Several standard library functions and POSIX directory functions cause hard faults when given NULL arguments.

I know it's a bad idea to ever allow a NULL argument to be passed to these functions, but it seems to me it should fail gracefully instead of causing a hard fault.

The following calls result in a hard fault:

freopen("path/to/file", "mode", NULL)
fread(NULL, nsize, nitems, pFile)
fwrite(NULL, nsize, nitems, pFile)
closedir(NULL)
readdir(NULL)
rewinddir(NULL)
fseek(NULL, offset, whence)

If I remember right, I think calling fclose() twice on the same handle or calling closedir() twice on the same directory handle may cause a hard fault as well, but that may be more difficult to protect against.

Tested on FRDM-K64F with mbed OS 3 (and possibly mbed 2 as well, I can't remember).

[sg-]

Can you provide a test case in the form of a program we can work against?

[aamcampbell]

Sure:

• Create a basic yotta mbed project for the FRDM-K64F (e.g. https://docs.mbed.com/docs/getting-started-mbed-os/en/latest/FirstProjectmbedOS/).
• Use this as your source file:

#include <stdio.h>
#include <mbed-drivers/DirHandle.h>
void app_start(int argc, char *argv[]) {
    // Any of the following function calls will cause a hard fault.
    freopen("asdf", "r", NULL);
    fwrite(NULL, 1, 1, stdout);
    closedir(NULL);
    readdir(NULL);
    rewinddir(NULL);
    fseek(NULL, 0, SEEK_SET);
}

I wasn't able to make fread() hard fault without loading a filesystem, so I'll leave that for later.

The harder part, if you aren't familiar with it, is debugging the program. I used Kinetis Design Studio for this, and I used the SEGGAR firmware on the target since it debugs faster.

[ciarmcom]

ARM Internal Ref: IOTMORF-488