4 ms·

Checking PVS-Studio with Clang

52 points by AndreyKarpov 12y ago

wolfgke 12y ago
According to http://stackoverflow.com/questions/6793262/why-dereferencing-a-null-pointer-is-undefined-behaviour http://stackoverflow.com/questions/6793262/why-dereferencing... dereferencing a null pointer is undefined behaviour. Thus the example in the unit test where this occurs is IMHO a serious bug.
- tokenrove 12y ago
  Note that in this case, what's actually happening is a null reference is being created; while this is very ugly (C++ references should never be null), if the reference isn't used, as the author asserts, a null dereference never happens (otherwise, there would almost inevitably be a crash). Behind the scenes it's just a NULL pointer being passed to the function that apparently ignores it.
  - sharth 12y ago
    But either way, the code is not well-formed. A null reference should never exist in a well-formed program. http://stackoverflow.com/questions/4364536/c-null-reference http://stackoverflow.com/questions/4364536/c-null-reference
ridiculous_fish 12y ago
The author's attitude towards UB is wrongheaded and dangerous. He argues: > The Get() function can initialize the variables A and B. Whether or not it has done so is marked in the variables getA and getB. Regardless of whether or not the variables A and B are initialized, their values are copied into TmpA and TmpB correspondingly....Formally, as far as I understand, undefined behavior occurs. In practice, however, just some garbage will be copied. This "in practice" is assuming a naive compiler that dutifully outputs a copy instruction. But the reality is compilers exploit undefined behavior for optimization opportunities. A likely outcome here is that the compiler will see UB if getA is false, and therefore optimize getA to just always be true. Not what the author intended at all! Chris Lattner explains it beautifully: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
- to3m 12y ago
  I post this guy's somewhat-related rant in response to any post I see in support of the modern approach to undefined behaviour: http://robertoconcerto.blogspot.co.uk/2010/10/strict-aliasing.html http://robertoconcerto.blogspot.co.uk/2010/10/strict-aliasin... (So, no matter which side of this argument you prefer, don't worry: you are not alone.)
  - userbinator 12y ago
    This is another one on the same side: http://blog.metaobject.com/2014/04/cc-osmartass.html http://blog.metaobject.com/2014/04/cc-osmartass.html I should point out the C standard explicitly says that "Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message)." The second choice is what programmers expect. UB should not be taken literally as "you can do anything". To take this to an extreme, a compiler that deletes any source files that contain UB could be compliant, but would also be one that no one ever wants. Much of the utility of C comes from its use as a "portable high-level assembler", meaning that its constructs are supposed to intuitively map almost directly to machine instructions. Aggressively optimising compilers that exploit UB violate this, so they are not in the spirit of the language: UB is either unintentional (a bug), in which case the compiler should issue a warning; or it is intentional, in which case the compiler should translate it with the intention the programmer had in mind. Making assumptions that "UB will never occur" and using that for optimisation is "wrongheaded and dangerous"; C's reputation for performance and efficiency comes from its simple low-level nature, not from overly aggressive compiler optimisation. Any optimising by the compiler should be at the instruction-selection level, and higher-level optimisation done with assumptions that are "characteristic of the environment". It's also worth mentioning that the "UB = optimisation" advocates seem to be mostly academics with an intense interest in replacing C with "safer" languages... and there's no better way to further their own agenda than to "legally" disparage C and make it a worse language than it should be.
    - 12y ago

52 points by AndreyKarpov 12y ago

According to http://stackoverflow.com/questions/6793262/why-dereferencing-a-null-pointer-is-undefined-behaviour http://stackoverflow.com/questions/6793262/why-dereferencing... dereferencing a null pointer is undefined behaviour. Thus the example in the unit test where this occurs is IMHO a serious bug.

tokenrove 12y ago
Note that in this case, what's actually happening is a null reference is being created; while this is very ugly (C++ references should never be null), if the reference isn't used, as the author asserts, a null dereference never happens (otherwise, there would almost inevitably be a crash). Behind the scenes it's just a NULL pointer being passed to the function that apparently ignores it.
- sharth 12y ago
  But either way, the code is not well-formed. A null reference should never exist in a well-formed program. http://stackoverflow.com/questions/4364536/c-null-reference http://stackoverflow.com/questions/4364536/c-null-reference

ridiculous_fish 12y ago

The author's attitude towards UB is wrongheaded and dangerous. He argues: > The Get() function can initialize the variables A and B. Whether or not it has done so is marked in the variables getA and getB. Regardless of whether or not the variables A and B are initialized, their values are copied into TmpA and TmpB correspondingly....Formally, as far as I understand, undefined behavior occurs. In practice, however, just some garbage will be copied. This "in practice" is assuming a naive compiler that dutifully outputs a copy instruction. But the reality is compilers exploit undefined behavior for optimization opportunities. A likely outcome here is that the compiler will see UB if getA is false, and therefore optimize getA to just always be true. Not what the author intended at all! Chris Lattner explains it beautifully: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

to3m 12y ago
I post this guy's somewhat-related rant in response to any post I see in support of the modern approach to undefined behaviour: http://robertoconcerto.blogspot.co.uk/2010/10/strict-aliasing.html http://robertoconcerto.blogspot.co.uk/2010/10/strict-aliasin... (So, no matter which side of this argument you prefer, don't worry: you are not alone.)
- userbinator 12y ago
  This is another one on the same side: http://blog.metaobject.com/2014/04/cc-osmartass.html http://blog.metaobject.com/2014/04/cc-osmartass.html I should point out the C standard explicitly says that "Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message)." The second choice is what programmers expect. UB should not be taken literally as "you can do anything". To take this to an extreme, a compiler that deletes any source files that contain UB could be compliant, but would also be one that no one ever wants. Much of the utility of C comes from its use as a "portable high-level assembler", meaning that its constructs are supposed to intuitively map almost directly to machine instructions. Aggressively optimising compilers that exploit UB violate this, so they are not in the spirit of the language: UB is either unintentional (a bug), in which case the compiler should issue a warning; or it is intentional, in which case the compiler should translate it with the intention the programmer had in mind. Making assumptions that "UB will never occur" and using that for optimisation is "wrongheaded and dangerous"; C's reputation for performance and efficiency comes from its simple low-level nature, not from overly aggressive compiler optimisation. Any optimising by the compiler should be at the instruction-selection level, and higher-level optimisation done with assumptions that are "characteristic of the environment". It's also worth mentioning that the "UB = optimisation" advocates seem to be mostly academics with an intense interest in replacing C with "safer" languages... and there's no better way to further their own agenda than to "legally" disparage C and make it a worse language than it should be.
  - 12y ago