Polyspace Run-time check alert with C open() function
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] = '';
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
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?
c runtime-error static-analysis misra fcntl
edited Nov 16 '18 at 8:58
Lundin
112k17163271
asked Nov 15 '18 at 15:20
Jorge Juan Torres QuirogaJorge Juan Torres Quiroga
599
add a comment |
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] = '';
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
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?
c runtime-error static-analysis misra fcntl
edited Nov 16 '18 at 8:58
Lundin
112k17163271
asked Nov 15 '18 at 15:20
Jorge Juan Torres QuirogaJorge Juan Torres Quiroga
599
1
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 ofbyte_countsomehow. Perhaps Polyspace doesn't realize that this is directly related to the written string length. You could experiment and add a linebyte_count = strlen(aux_buf);below thesnprintfand 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 withsnprintf.
– 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 7:59
Sounds like a tool defect then. Implicit conversions fromchar*toconst char*are perfectly safe and encouraged practice, by MISRA-C and others.
– Lundin
Nov 16 '18 at 8:57
add a comment |
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] = '';
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
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?
c runtime-error static-analysis misra fcntl
edited Nov 16 '18 at 8:58
Lundin
112k17163271
asked Nov 15 '18 at 15:20
Jorge Juan Torres QuirogaJorge Juan Torres Quiroga
599
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] = '';
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
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?
c runtime-error static-analysis misra fcntl
c runtime-error static-analysis misra fcntl
edited Nov 16 '18 at 8:58
Lundin
112k17163271
asked Nov 15 '18 at 15:20
Jorge Juan Torres QuirogaJorge Juan Torres Quiroga
599
edited Nov 16 '18 at 8:58
Lundin
112k17163271
asked Nov 15 '18 at 15:20
Jorge Juan Torres QuirogaJorge Juan Torres Quiroga
599
edited Nov 16 '18 at 8:58
Lundin
112k17163271
edited Nov 16 '18 at 8:58
Lundin
112k17163271
edited Nov 16 '18 at 8:58
Lundin
112k17163271
112k17163271
asked Nov 15 '18 at 15:20
Jorge Juan Torres QuirogaJorge Juan Torres Quiroga
599
asked Nov 15 '18 at 15:20
Jorge Juan Torres QuirogaJorge Juan Torres Quiroga
599
asked Nov 15 '18 at 15:20
Jorge Juan Torres QuirogaJorge Juan Torres Quiroga
599
599
1
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 ofbyte_countsomehow. Perhaps Polyspace doesn't realize that this is directly related to the written string length. You could experiment and add a linebyte_count = strlen(aux_buf);below thesnprintfand 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 withsnprintf.
– 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 7:59
Sounds like a tool defect then. Implicit conversions fromchar*toconst char*are perfectly safe and encouraged practice, by MISRA-C and others.
– Lundin
Nov 16 '18 at 8:57
add a comment |
1
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 ofbyte_countsomehow. Perhaps Polyspace doesn't realize that this is directly related to the written string length. You could experiment and add a linebyte_count = strlen(aux_buf);below thesnprintfand 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 withsnprintf.
– 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 7:59
Sounds like a tool defect then. Implicit conversions fromchar*toconst char*are perfectly safe and encouraged practice, by MISRA-C and others.
– Lundin
Nov 16 '18 at 8:57
1
1
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
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
@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
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 7:59
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 7: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 8:57
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 8:57
add a comment |
1 Answer
1
active
oldest
votes
The issue has been judged to be a false positive. The alerts shall be justified accordingly.
Thanks!
answered Nov 20 '18 at 8:27
Jorge Juan Torres QuirogaJorge Juan Torres Quiroga
599
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53322592%2fpolyspace-run-time-check-alert-with-c-open-function%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The issue has been judged to be a false positive. The alerts shall be justified accordingly.
Thanks!
answered Nov 20 '18 at 8:27
Jorge Juan Torres QuirogaJorge Juan Torres Quiroga
599
add a comment |
The issue has been judged to be a false positive. The alerts shall be justified accordingly.
Thanks!
answered Nov 20 '18 at 8:27
Jorge Juan Torres QuirogaJorge Juan Torres Quiroga
599
add a comment |
The issue has been judged to be a false positive. The alerts shall be justified accordingly.
Thanks!
answered Nov 20 '18 at 8:27
Jorge Juan Torres QuirogaJorge Juan Torres Quiroga
599
The issue has been judged to be a false positive. The alerts shall be justified accordingly.
Thanks!
answered Nov 20 '18 at 8:27
Jorge Juan Torres QuirogaJorge Juan Torres Quiroga
599
answered Nov 20 '18 at 8:27
Jorge Juan Torres QuirogaJorge Juan Torres Quiroga
599
answered Nov 20 '18 at 8:27
Jorge Juan Torres QuirogaJorge Juan Torres Quiroga
599
answered Nov 20 '18 at 8:27
Jorge Juan Torres QuirogaJorge Juan Torres Quiroga
599
599
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53322592%2fpolyspace-run-time-check-alert-with-c-open-function%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
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_countsomehow. Perhaps Polyspace doesn't realize that this is directly related to the written string length. You could experiment and add a linebyte_count = strlen(aux_buf);below thesnprintfand 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 withsnprintf.– 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 7:59
Sounds like a tool defect then. Implicit conversions from
char*toconst char*are perfectly safe and encouraged practice, by MISRA-C and others.– Lundin
Nov 16 '18 at 8:57