Polyspace alerts about use of system-defined parameter flags for system functions
up vote
2
down vote
favorite
I am working with Polyspace Code Prover and Bug Finder to perform the static analysis of my Linux application written in C.
We are getting several alerts regarding the use of flags as defined by the "man" pages of said calls. In the man pages of functions like open(), write() or syslog(), we can see that they have a parameter which we can pass as an OR of several flags defined by the interface, like in the following example:
fd_value = shm_open(shm_key, O_CREAT | O_RDWR | O_EXCL , S_IRWXU);
Polyspace complains that, in the example above, the flags O_CREAT, O_RDWR and O_EXCL are of different essential types (some unsigned, some signed), and thus such an OR operation is not recommended. This is true according to MISRA's 10.1 guideline, but if that's how the system defines its API and its values what can I do about it? Seems to me like casting the values just to make the tool happy is risky.
Is there any other way around the problem besides justifying those violations?
Thank you, best regards!
c static-analysis misra
asked Nov 19 at 16:33
Jorge Juan Torres Quiroga
469
|
show 3 more comments
up vote
2
down vote
favorite
I am working with Polyspace Code Prover and Bug Finder to perform the static analysis of my Linux application written in C.
We are getting several alerts regarding the use of flags as defined by the "man" pages of said calls. In the man pages of functions like open(), write() or syslog(), we can see that they have a parameter which we can pass as an OR of several flags defined by the interface, like in the following example:
fd_value = shm_open(shm_key, O_CREAT | O_RDWR | O_EXCL , S_IRWXU);
Polyspace complains that, in the example above, the flags O_CREAT, O_RDWR and O_EXCL are of different essential types (some unsigned, some signed), and thus such an OR operation is not recommended. This is true according to MISRA's 10.1 guideline, but if that's how the system defines its API and its values what can I do about it? Seems to me like casting the values just to make the tool happy is risky.
Is there any other way around the problem besides justifying those violations?
Thank you, best regards!
c static-analysis misra
asked Nov 19 at 16:33
Jorge Juan Torres Quiroga
469
1
What happens if you "cheat" by casts? E.g.shm_open(shm_key, (int)((unsigned)(O_CREAT) | (unsigned)(O_RDWR) | (unsigned)(O_EXCL)), S_IRWXU);. I guess, these functions/values were defined at a time where the differences betweenintandunsignedin bit arithmetics were not considered that hard. ;-)
– Scheff
Nov 19 at 17:38
1
I don't think Linux and MISRA-C will come to love each other much. Essentially you are asking: why isshm_openwritten like crap? Good question. It takes some considerable obfuscation skill to get different signedness of those enums, particularly since standard C demands that enumeration constants are of typeintand the function takesintas parameter.
– Lundin
Nov 20 at 15:30
1
@JorgeJuanTorresQuiroga For "hardcore" MISRA-C implementations, you don't allow any C code in the project not to follow MISRA-C, including libraries. For "MISRA-C light", you can make exceptions. Mostly it depends on if the application is actually a mission-critical one, or if you are just using MISRA-C as a bug-killing standard to improve quality. In case of the former, the answer is simply: this library cannot be used for this application, because it is sloppily written.
– Lundin
Nov 21 at 10:37
1
@JorgeJuanTorresQuiroga Yeah in that case a deviation from the rule is probably the best way to go, for the use of this specific function.
– Lundin
Nov 22 at 8:44
1
The standard libraries are full of poor code, that "works" - but is not as "correct" as it could be. MISRA Compliance tries to help with adopted code but until the Standard defines things "correctly" we all have these sort of issues :(
– Andrew
yesterday
|
show 3 more comments
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I am working with Polyspace Code Prover and Bug Finder to perform the static analysis of my Linux application written in C.
We are getting several alerts regarding the use of flags as defined by the "man" pages of said calls. In the man pages of functions like open(), write() or syslog(), we can see that they have a parameter which we can pass as an OR of several flags defined by the interface, like in the following example:
fd_value = shm_open(shm_key, O_CREAT | O_RDWR | O_EXCL , S_IRWXU);
Polyspace complains that, in the example above, the flags O_CREAT, O_RDWR and O_EXCL are of different essential types (some unsigned, some signed), and thus such an OR operation is not recommended. This is true according to MISRA's 10.1 guideline, but if that's how the system defines its API and its values what can I do about it? Seems to me like casting the values just to make the tool happy is risky.
Is there any other way around the problem besides justifying those violations?
Thank you, best regards!
c static-analysis misra
asked Nov 19 at 16:33
Jorge Juan Torres Quiroga
469
I am working with Polyspace Code Prover and Bug Finder to perform the static analysis of my Linux application written in C.
We are getting several alerts regarding the use of flags as defined by the "man" pages of said calls. In the man pages of functions like open(), write() or syslog(), we can see that they have a parameter which we can pass as an OR of several flags defined by the interface, like in the following example:
fd_value = shm_open(shm_key, O_CREAT | O_RDWR | O_EXCL , S_IRWXU);
Polyspace complains that, in the example above, the flags O_CREAT, O_RDWR and O_EXCL are of different essential types (some unsigned, some signed), and thus such an OR operation is not recommended. This is true according to MISRA's 10.1 guideline, but if that's how the system defines its API and its values what can I do about it? Seems to me like casting the values just to make the tool happy is risky.
Is there any other way around the problem besides justifying those violations?
Thank you, best regards!
c static-analysis misra
c static-analysis misra
asked Nov 19 at 16:33
Jorge Juan Torres Quiroga
469
asked Nov 19 at 16:33
Jorge Juan Torres Quiroga
469
asked Nov 19 at 16:33
Jorge Juan Torres Quiroga
469
asked Nov 19 at 16:33
Jorge Juan Torres Quiroga
469
asked Nov 19 at 16:33
Jorge Juan Torres Quiroga
469
469
1
What happens if you "cheat" by casts? E.g.shm_open(shm_key, (int)((unsigned)(O_CREAT) | (unsigned)(O_RDWR) | (unsigned)(O_EXCL)), S_IRWXU);. I guess, these functions/values were defined at a time where the differences betweenintandunsignedin bit arithmetics were not considered that hard. ;-)
– Scheff
Nov 19 at 17:38
1
I don't think Linux and MISRA-C will come to love each other much. Essentially you are asking: why isshm_openwritten like crap? Good question. It takes some considerable obfuscation skill to get different signedness of those enums, particularly since standard C demands that enumeration constants are of typeintand the function takesintas parameter.
– Lundin
Nov 20 at 15:30
1
@JorgeJuanTorresQuiroga For "hardcore" MISRA-C implementations, you don't allow any C code in the project not to follow MISRA-C, including libraries. For "MISRA-C light", you can make exceptions. Mostly it depends on if the application is actually a mission-critical one, or if you are just using MISRA-C as a bug-killing standard to improve quality. In case of the former, the answer is simply: this library cannot be used for this application, because it is sloppily written.
– Lundin
Nov 21 at 10:37
1
@JorgeJuanTorresQuiroga Yeah in that case a deviation from the rule is probably the best way to go, for the use of this specific function.
– Lundin
Nov 22 at 8:44
1
The standard libraries are full of poor code, that "works" - but is not as "correct" as it could be. MISRA Compliance tries to help with adopted code but until the Standard defines things "correctly" we all have these sort of issues :(
– Andrew
yesterday
|
show 3 more comments
1
What happens if you "cheat" by casts? E.g.shm_open(shm_key, (int)((unsigned)(O_CREAT) | (unsigned)(O_RDWR) | (unsigned)(O_EXCL)), S_IRWXU);. I guess, these functions/values were defined at a time where the differences betweenintandunsignedin bit arithmetics were not considered that hard. ;-)
– Scheff
Nov 19 at 17:38
1
I don't think Linux and MISRA-C will come to love each other much. Essentially you are asking: why isshm_openwritten like crap? Good question. It takes some considerable obfuscation skill to get different signedness of those enums, particularly since standard C demands that enumeration constants are of typeintand the function takesintas parameter.
– Lundin
Nov 20 at 15:30
1
@JorgeJuanTorresQuiroga For "hardcore" MISRA-C implementations, you don't allow any C code in the project not to follow MISRA-C, including libraries. For "MISRA-C light", you can make exceptions. Mostly it depends on if the application is actually a mission-critical one, or if you are just using MISRA-C as a bug-killing standard to improve quality. In case of the former, the answer is simply: this library cannot be used for this application, because it is sloppily written.
– Lundin
Nov 21 at 10:37
1
@JorgeJuanTorresQuiroga Yeah in that case a deviation from the rule is probably the best way to go, for the use of this specific function.
– Lundin
Nov 22 at 8:44
1
The standard libraries are full of poor code, that "works" - but is not as "correct" as it could be. MISRA Compliance tries to help with adopted code but until the Standard defines things "correctly" we all have these sort of issues :(
– Andrew
yesterday
1
1
What happens if you "cheat" by casts? E.g.
shm_open(shm_key, (int)((unsigned)(O_CREAT) | (unsigned)(O_RDWR) | (unsigned)(O_EXCL)), S_IRWXU);. I guess, these functions/values were defined at a time where the differences between int and unsigned in bit arithmetics were not considered that hard. ;-)– Scheff
Nov 19 at 17:38
What happens if you "cheat" by casts? E.g.
shm_open(shm_key, (int)((unsigned)(O_CREAT) | (unsigned)(O_RDWR) | (unsigned)(O_EXCL)), S_IRWXU);. I guess, these functions/values were defined at a time where the differences between int and unsigned in bit arithmetics were not considered that hard. ;-)– Scheff
Nov 19 at 17:38
1
1
I don't think Linux and MISRA-C will come to love each other much. Essentially you are asking: why is
shm_open written like crap? Good question. It takes some considerable obfuscation skill to get different signedness of those enums, particularly since standard C demands that enumeration constants are of type int and the function takes int as parameter.– Lundin
Nov 20 at 15:30
I don't think Linux and MISRA-C will come to love each other much. Essentially you are asking: why is
shm_open written like crap? Good question. It takes some considerable obfuscation skill to get different signedness of those enums, particularly since standard C demands that enumeration constants are of type int and the function takes int as parameter.– Lundin
Nov 20 at 15:30
1
1
@JorgeJuanTorresQuiroga For "hardcore" MISRA-C implementations, you don't allow any C code in the project not to follow MISRA-C, including libraries. For "MISRA-C light", you can make exceptions. Mostly it depends on if the application is actually a mission-critical one, or if you are just using MISRA-C as a bug-killing standard to improve quality. In case of the former, the answer is simply: this library cannot be used for this application, because it is sloppily written.
– Lundin
Nov 21 at 10:37
@JorgeJuanTorresQuiroga For "hardcore" MISRA-C implementations, you don't allow any C code in the project not to follow MISRA-C, including libraries. For "MISRA-C light", you can make exceptions. Mostly it depends on if the application is actually a mission-critical one, or if you are just using MISRA-C as a bug-killing standard to improve quality. In case of the former, the answer is simply: this library cannot be used for this application, because it is sloppily written.
– Lundin
Nov 21 at 10:37
1
1
@JorgeJuanTorresQuiroga Yeah in that case a deviation from the rule is probably the best way to go, for the use of this specific function.
– Lundin
Nov 22 at 8:44
@JorgeJuanTorresQuiroga Yeah in that case a deviation from the rule is probably the best way to go, for the use of this specific function.
– Lundin
Nov 22 at 8:44
1
1
The standard libraries are full of poor code, that "works" - but is not as "correct" as it could be. MISRA Compliance tries to help with adopted code but until the Standard defines things "correctly" we all have these sort of issues :(
– Andrew
yesterday
The standard libraries are full of poor code, that "works" - but is not as "correct" as it could be. MISRA Compliance tries to help with adopted code but until the Standard defines things "correctly" we all have these sort of issues :(
– Andrew
yesterday
|
show 3 more comments
1 Answer
1
active
oldest
votes
up vote
0
down vote
It is somewhat strange that those values are defined with different signess. It may be a good idea to add a platform isolation layer that will redefine those constants into module-specific constants performing necessary casts and probably dealing with cross-platform differences.
typedef int t_my_shm_open_flags;
#if(defined(PLATFORM1))
#define MY_SHM_OPEN_FLAG_CREATE ((t_my_shm_open_flags) O_CREAT)
#define MY_SHM_OPEN_FLAG_READ_WRITE ((t_my_shm_open_flags) O_RDWR)
#define MY_SHM_OPEN_FLAG_EXCLUSIVE ((t_my_shm_open_flags) O_EXCL)
#else
/* error for unsupported platform */
#endif
#define MY_SHM_OPEN_DEFAULT_FLAGS (MY_SHM_OPEN_FLAG_CREATE | MY_SHM_OPEN_FLAG_READ_WRITE | MY_SHM_OPEN_FLAG_EXCLUSIVE)
answered Nov 19 at 22:59
VTT
23.4k42345
2
The cause is most likely a design flaw in the library code. We shouldn't need to produce dirty hacks to use a function as intended.
– Lundin
Nov 20 at 15:34
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
It is somewhat strange that those values are defined with different signess. It may be a good idea to add a platform isolation layer that will redefine those constants into module-specific constants performing necessary casts and probably dealing with cross-platform differences.
typedef int t_my_shm_open_flags;
#if(defined(PLATFORM1))
#define MY_SHM_OPEN_FLAG_CREATE ((t_my_shm_open_flags) O_CREAT)
#define MY_SHM_OPEN_FLAG_READ_WRITE ((t_my_shm_open_flags) O_RDWR)
#define MY_SHM_OPEN_FLAG_EXCLUSIVE ((t_my_shm_open_flags) O_EXCL)
#else
/* error for unsupported platform */
#endif
#define MY_SHM_OPEN_DEFAULT_FLAGS (MY_SHM_OPEN_FLAG_CREATE | MY_SHM_OPEN_FLAG_READ_WRITE | MY_SHM_OPEN_FLAG_EXCLUSIVE)
answered Nov 19 at 22:59
VTT
23.4k42345
2
The cause is most likely a design flaw in the library code. We shouldn't need to produce dirty hacks to use a function as intended.
– Lundin
Nov 20 at 15:34
add a comment |
up vote
0
down vote
It is somewhat strange that those values are defined with different signess. It may be a good idea to add a platform isolation layer that will redefine those constants into module-specific constants performing necessary casts and probably dealing with cross-platform differences.
typedef int t_my_shm_open_flags;
#if(defined(PLATFORM1))
#define MY_SHM_OPEN_FLAG_CREATE ((t_my_shm_open_flags) O_CREAT)
#define MY_SHM_OPEN_FLAG_READ_WRITE ((t_my_shm_open_flags) O_RDWR)
#define MY_SHM_OPEN_FLAG_EXCLUSIVE ((t_my_shm_open_flags) O_EXCL)
#else
/* error for unsupported platform */
#endif
#define MY_SHM_OPEN_DEFAULT_FLAGS (MY_SHM_OPEN_FLAG_CREATE | MY_SHM_OPEN_FLAG_READ_WRITE | MY_SHM_OPEN_FLAG_EXCLUSIVE)
answered Nov 19 at 22:59
VTT
23.4k42345
2
The cause is most likely a design flaw in the library code. We shouldn't need to produce dirty hacks to use a function as intended.
– Lundin
Nov 20 at 15:34
add a comment |
up vote
0
down vote
up vote
0
down vote
It is somewhat strange that those values are defined with different signess. It may be a good idea to add a platform isolation layer that will redefine those constants into module-specific constants performing necessary casts and probably dealing with cross-platform differences.
typedef int t_my_shm_open_flags;
#if(defined(PLATFORM1))
#define MY_SHM_OPEN_FLAG_CREATE ((t_my_shm_open_flags) O_CREAT)
#define MY_SHM_OPEN_FLAG_READ_WRITE ((t_my_shm_open_flags) O_RDWR)
#define MY_SHM_OPEN_FLAG_EXCLUSIVE ((t_my_shm_open_flags) O_EXCL)
#else
/* error for unsupported platform */
#endif
#define MY_SHM_OPEN_DEFAULT_FLAGS (MY_SHM_OPEN_FLAG_CREATE | MY_SHM_OPEN_FLAG_READ_WRITE | MY_SHM_OPEN_FLAG_EXCLUSIVE)
answered Nov 19 at 22:59
VTT
23.4k42345
It is somewhat strange that those values are defined with different signess. It may be a good idea to add a platform isolation layer that will redefine those constants into module-specific constants performing necessary casts and probably dealing with cross-platform differences.
typedef int t_my_shm_open_flags;
#if(defined(PLATFORM1))
#define MY_SHM_OPEN_FLAG_CREATE ((t_my_shm_open_flags) O_CREAT)
#define MY_SHM_OPEN_FLAG_READ_WRITE ((t_my_shm_open_flags) O_RDWR)
#define MY_SHM_OPEN_FLAG_EXCLUSIVE ((t_my_shm_open_flags) O_EXCL)
#else
/* error for unsupported platform */
#endif
#define MY_SHM_OPEN_DEFAULT_FLAGS (MY_SHM_OPEN_FLAG_CREATE | MY_SHM_OPEN_FLAG_READ_WRITE | MY_SHM_OPEN_FLAG_EXCLUSIVE)
answered Nov 19 at 22:59
VTT
23.4k42345
answered Nov 19 at 22:59
VTT
23.4k42345
answered Nov 19 at 22:59
VTT
23.4k42345
answered Nov 19 at 22:59
VTT
23.4k42345
23.4k42345
2
The cause is most likely a design flaw in the library code. We shouldn't need to produce dirty hacks to use a function as intended.
– Lundin
Nov 20 at 15:34
add a comment |
2
The cause is most likely a design flaw in the library code. We shouldn't need to produce dirty hacks to use a function as intended.
– Lundin
Nov 20 at 15:34
2
2
The cause is most likely a design flaw in the library code. We shouldn't need to produce dirty hacks to use a function as intended.
– Lundin
Nov 20 at 15:34
The cause is most likely a design flaw in the library code. We shouldn't need to produce dirty hacks to use a function as intended.
– Lundin
Nov 20 at 15:34
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f53379004%2fpolyspace-alerts-about-use-of-system-defined-parameter-flags-for-system-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 happens if you "cheat" by casts? E.g.
shm_open(shm_key, (int)((unsigned)(O_CREAT) | (unsigned)(O_RDWR) | (unsigned)(O_EXCL)), S_IRWXU);. I guess, these functions/values were defined at a time where the differences betweenintandunsignedin bit arithmetics were not considered that hard. ;-)– Scheff
Nov 19 at 17:38
1
I don't think Linux and MISRA-C will come to love each other much. Essentially you are asking: why is
shm_openwritten like crap? Good question. It takes some considerable obfuscation skill to get different signedness of those enums, particularly since standard C demands that enumeration constants are of typeintand the function takesintas parameter.– Lundin
Nov 20 at 15:30
1
@JorgeJuanTorresQuiroga For "hardcore" MISRA-C implementations, you don't allow any C code in the project not to follow MISRA-C, including libraries. For "MISRA-C light", you can make exceptions. Mostly it depends on if the application is actually a mission-critical one, or if you are just using MISRA-C as a bug-killing standard to improve quality. In case of the former, the answer is simply: this library cannot be used for this application, because it is sloppily written.
– Lundin
Nov 21 at 10:37
1
@JorgeJuanTorresQuiroga Yeah in that case a deviation from the rule is probably the best way to go, for the use of this specific function.
– Lundin
Nov 22 at 8:44
1
The standard libraries are full of poor code, that "works" - but is not as "correct" as it could be. MISRA Compliance tries to help with adopted code but until the Standard defines things "correctly" we all have these sort of issues :(
– Andrew
yesterday