Polyspace Run-time check alert with C open() function

Question

First, please consider the following piece of code (static function called once from main()):

#define SYSFS_GPIO_DIR                          "/sys/class/gpio"
#define MAX_BUF                                 ((UI_8)64)

typedef uint8_t UI_8
typedef int32_t SI_32
typedef char CHAR_8

static SI_32 ImuGpioFdOpen(UI_8 gpio)
{
    SI_32 fd_gpio_open = -1;
    SI_32 byte_count = -1;
    CHAR_8 aux_buf[MAX_BUF] = {'\0'};

    byte_count = snprintf(aux_buf, sizeof(aux_buf), SYSFS_GPIO_DIR "/gpio%d/value", gpio);
    if((byte_count > 0) && (byte_count < sizeof(aux_buf))){
        fd_gpio_open = open(aux_buf, O_RDONLY | O_NONBLOCK );
        if(fd_gpio_open < 0){
            syslog (LOG_ERR,"gpio/fd_open");
            fd_gpio_open = ERROR;
        }
    }

    return fd_gpio_open;
}/*ImuGpioFdOpen*/

On the call to open(), static analysis with Polyspace Code Prover raises and alert regarding MISRA's "Dir 4.1 Run-time failures shall be minimized". The alerts says that: "first argument (file path) may not be a valid string"

We don't seem to understand the directive very well, because all our efforts to solve the alerts like this (we have several similar ones) are not yielding results. I mean, we are clearly not building the string correctly, but since the program compiles and runs correctly, we are at a loss.

What kind of run-time check are we missing?

Thank you!

EDIT: I forgot to mention that passing a string literal seems to work for Polyspace, but it doesn't work if we try to pass string generated at runtime (like in the code). Could it be because open()'s prototype declares that the first argument is const char* and Polyspace is taking it too seriously?

What makes you think this is a valid diagnostic and not a false positive? MISRA-C makes a difference between directives and rules, directives being things that cannot be fully checked statically. MISRA-C 6.1 warns that static analysers might have wildly different interpretations here. Personally I would be sceptic against any tool giving warnings for directives. 4.1 specifically contains things I would expect to be handled through code review, not through static analysis. And I can't find anything wrong with your code. — Lundin, Nov 15 '18 at 15:52
@Lundin thanks for the quick response! I forgot to mention that passing a string literal seems to work for Polyspace, but it doesn't work if we try to pass string generated at runtime (like in the code). Could it be because open()'s prototype declares that the first argument is const char* and Polyspace is taking it too seriously? — Jorge Juan Torres Quiroga, Nov 15 '18 at 16:03
No, the argument to open() shouldn't matter. I think this is related to the bounds-check of `byte_count` somehow. Perhaps Polyspace doesn't realize that this is directly related to the written string length. You could experiment and add a line `byte_count = strlen(aux_buf);` below the `snprintf` and see if it does any difference. Otherwise, the tool might also be concerned with the string not being properly null terminated, but I don't see how that could happen here with `snprintf`. — Lundin, Nov 15 '18 at 17:54
I am going to address that bounds check just in case, but I have been analysing every similar alert we have of this nature and they all have in common that the tool complains about const char* arguments receiving non-literal strings. Even strlen fails with the same message if we try to pass it anything other than a const char* — Jorge Juan Torres Quiroga, Nov 16 '18 at 07:59
Sounds like a tool defect then. Implicit conversions from `char*` to `const char*` are perfectly safe and encouraged practice, by MISRA-C and others. — Lundin, Nov 16 '18 at 08:57

score 0 · Accepted Answer · answered Nov 20 '18 at 08:27

0

The issue has been judged to be a false positive. The alerts shall be justified accordingly.

Thanks!

answered Nov 20 '18 at 08:27

Jorge Juan Torres Quiroga

99
10

Polyspace Run-time check alert with C open() function

1 Answers1