9 ms·

a = a; // misra Actual code i have seen with my own eyes. (Not in F-35 code) Its a way to avoid removing an unused parameter from a method. Unused parameters

by time4tea 10mo ago

a = a; // misra Actual code i have seen with my own eyes. (Not in F-35 code) Its a way to avoid removing an unused parameter from a method. Unused parameters are disallowed, but this is fine? I am sceptical that these coding standards make for good code!

msla 10mo ago
Especially since there is a widely recognized way to ignore a parameter: (void) a; Every C programmer beyond weaning knows that.
- stefan_ 10mo ago
  I'm sure thats disallowed for the C-style cast.
  - daringrain32781 10mo ago
    C++17 has the [[maybe_unused]] attribute.
  - cpgxiii 10mo ago
    Fwiw, unused-cast-to-void is a case that GCC and Clang ignore when using -Wno-old-style-cast, which is what most projects prohibiting C-style casts are going to be using (or whatever the equivalent their compiler provides).
- deleted 10mo ago
  [deleted]
- time4tea 10mo ago
  The point really was that the unused method parameter should in almost all cases be removed, not that some trick should be used to make it seem used, and this is the wrong trick!
  - addaon 10mo ago
    Sometimes. But sometimes you have a set of functions that are called through function pointers that need the same signature, and one or more of them ignore some of the arguments. These days I’d spell that __attribute__((unused)); but it’s a perfectly reasonable case.
  - bluGill 10mo ago
    #if otherbuild dosomething(param); #endif the above type of thing happens once in a while. nos the paramater is needed but the normal build doesn't use it
unwind 10mo ago
For C, the proper/expected/standard way to reference a variable without accessing it is a cast to void: (void) a; I'm sure there are commonly-implemented compiler extensions, but this is the normal/native way and should always work.
- amluto 10mo ago
  Not if you use GCC. https://godbolt.org/z/zYdc9ej88 https://godbolt.org/z/zYdc9ej88 clang gets this right.
  - comex 10mo ago
    It does work in GCC to suppress unused variable warnings. Just not for function calls I guess.
    - cminmin 10mo ago
      __attribute__((maybe_unused)) or [[maybe_unused]] or such things (dependin on ur spec version i guess?) can be used not to disable a whole line of errors.
  - Am4TIfIsER0ppos 10mo ago
    You've defined that function with an attribute saying not to ignore the returned value. Is it right to explicitly silence an explicit warning?
    - MathMonkeyMan 10mo ago
      Sometimes. For example, you might be setting a non-crucial option on a socket, and if it fails you don't even care to log the fact (maybe the logging would be too expensive), so you just ignore the return value of whatever library is wrapping setsockopt.
    - amluto 10mo ago
      I want some defined way to tell the compiler that I am intentionally ignoring the result. I encounter this when trying to do best-effort logging in a failure path. I call some function to log and error and maybe it fails. If it does, what, exactly, am I going to do about it? Log harder?
ivanjermakov 10mo ago
Zig makes it explicit with _ = a; And you would encounter it quite often because unused variable is a compilation error: https://github.com/ziglang/zig/issues/335 https://github.com/ziglang/zig/issues/335
- ErroneousBosh 10mo ago
  Golang is exactly the same. It's extremely annoying until it's suddenly very useful and has prevented you doing something unintended.
  - bluecalm 10mo ago
    I fail to see how a warning doesn't achieve the same thing while allowing you to iterate faster. Unless you're working with barbarians who commit code that complies with warnings to your repo and there is 0 discipline to stop them.
    - treyd 10mo ago
      You're not supposed to question the wisdom of the Go developers. They had a very good reason for making unused variables be an unconfigurable hard error, and they don't need to rigorously justify it.
      - FieryMechanic 10mo ago
        Warnings are often ignored by developers unless you specifically force warnings to be compile errors (you can do this in most compiler). I work on TypeScript/C# code-bases and unless you force people to tidy up unused imports/using and variables, people will just leave them there. This BTW can cause issues with dependency chains and cause odd compile issues as a result.
        account42 10mo ago
        > Warnings are often ignored by developers unless you specifically force warnings to be compile errors (you can do this in most compiler). Not my experience. Find better managers.
binary132 10mo ago
It’s very weird how none of the sibling comments understood what it were saying is wrong with this.
- binary132 10mo ago
  Erm, sorry about the weird typo. Didn’t notice. Can’t edit now.
tialaramex 10mo ago
Studies have looked at MISRA, I'm not aware of any for the JSF guidelines. For MISRA there's a mix, some of the rules seem to be effective (fewer defects in compliant software), some are the opposite (code which obeys these rules is more likely to have defects) and some were irrelevant. Notably this document is from 2005. So that's after C++ was standardized but before their second bite of that particular cherry and twenty years before its author, Bjarne Stroustrup suddenly decides after years of insisting that C++ dialects are a terrible idea and will never be endorsed by the language committee, that in fact dialects (now named "profiles") are the magic ingredient to fix the festering problems with the language. While Laurie's video is fun, I too am sceptical about the value of style guides, which is what these are. "TABS shall be avoided" or "Letters in function names shall be lowercase" isn't because somebody's aeroplane fell out of the sky - it's due to using a style Bjarne doesn't like.
- writtiewrat 10mo ago
  [flagged]
  - tialaramex 10mo ago
    "No semantic effect" is one of those recurring C++ tropes like the "subset of a superset" or "trading performance for safety" that I think even its defenders ought to call bullshit on. The insistence on "No semantic effect" for attributes has poisoned them badly, and the choice to just ignore the semantic implications for Bjarne's C++ 20 Concepts makes this a poor substitute for the concepts feature as once imagined at the start of the century. I doubt I can satisfy you as to whether I'm somehow a paid evangelist, I remember I got a free meal once for contributing to the OSM project, and I bet if I dig further I can find some other occasion that, if you spin it hard enough can be justified as "payment" for my opinion that Rust is a good language. There was a nice lady giving our free cookies at the anti-racist counter-protests the other week, maybe she once met a guy who worked for an outfit which was contracted to print a Rust book? I sense you may own a corkboard and a lot of red string.
    - vlovich123 10mo ago
jjmarr 10mo ago
An unused parameter should be commented out.
- MobiusHorizons 10mo ago
  Unless it’s there to conform to an interface
  - jjmarr 10mo ago
    Especially if it's there to conform to an interface. You can comment out the variable name and leave the type.
y1n0 10mo ago
The standards don't remove the need for code review. In fact they provide a standard to be used in code review. Anything you can automate is nice, but when you have exceptions to rules that say "Exception, if there's no reasonable way to do X then Y is acceptable" isn't really something you can codify into static analysis.
deleted 10mo ago
[deleted]
jojobas 10mo ago
Isn't it inevitable for some cases of inheritance? A superclass does something basic and doesn't need all parameters, child classes require additional ones.
platinumrad 10mo ago
I've (unfortunately) written plenty of "safety critical" code professionally and coding standards definitely have a negative effect overall. The thing keeping planes from falling out of the sky is careful design, which in practice means fail-safes, watchdogs, redundancy, and most-importantly, requirements that aren't overly ambitious. While maybe 10% of rules are sensible, these sensible rules also tend to be blindingly obvious, or at least table stakes on embedded systems (e.g. don't try to allocate on a system which probably doesn't have a full libc in the first place).
- dilyevsky 10mo ago
  Many coding standards rules have nothing to do with correctness and everything to do with things like readability and reducing cognitive load (“which style should I use here?”)
qart 10mo ago
You're right. MISRA is a cult. Actual studies[1][2] have shown many of their rules to be harmful rather than helpful. I have worked in multiple safety-critical industries. MISRA is almost always enforced by bureaucrats who don't understand source code at all, or by senior developers who rose up ranks as code monkeys. One such manager was impressed with Matlab because Matlab-generated C code was always MISRA compliant, whereas the code my company was giving them had violations. Never mind the fact that every function of the generated, compliant code had variables like tmp01, tmp02, tmp03, etc. There are many areas of software where bureaucracy requires MISRA compliance, but that aren't really safety-critical. The code is a hot mess. There are other areas that require MISRA compliance and the domain is actually safety-critical (e.g. automotive software). Here, the saving grace is (1) low complexity of each CPU's codebase and (2) extensive testing. To people who want actual safety, security, portability, I tell them to learn from examples set by the Linux kernel, SQLite, OpenSSL, FFMpeg, etc. Modern linters (even free ones) are actually valuable compared to MISRA compliance checkers. [1] https://ieeexplore.ieee.org/abstract/document/4658076 https://ieeexplore.ieee.org/abstract/document/4658076 [2] https://repository.tudelft.nl/record/uuid:646de5ba-eee8-4ec8-8bbc-2c188e1847ea https://repository.tudelft.nl/record/uuid:646de5ba-eee8-4ec8...
- sam_bristow 10mo ago
  One key point that people overlook with that paper is that they were applying the coding standards retroactively. Taking an existing codebase, running compliance tools, and trying to fix the issues which were flagged. I think they correctly identified the issue with this approach in that you have all the risks of introducing defects as part of reworking the existing code. I don't think they have much empirical evidence for the case where coding standards were applied from the beginning of a project. In my opinion, the MISRA C++ 2023 revision is a massive improvement over the 2008 edition. It was a major rethink and has a lot more generally useful guidance. Either way, you need to tailor the standards to your project. Even the MISRA standards authors agree: """ Blind adherence to the letter without understanding is pointless. Anyone who stipulates 100% MISRA-C coverage with no deviations does not understand what the are asking for. In my opionion they should be taken out and... well... Just taken out. - Chris Hill, Member of MISRA C Working Group (MISRA Matters Column, MTE, June 2012 """

msla 10mo ago

Especially since there is a widely recognized way to ignore a parameter: (void) a; Every C programmer beyond weaning knows that.

stefan_ 10mo ago
I'm sure thats disallowed for the C-style cast.
- daringrain32781 10mo ago
  C++17 has the [[maybe_unused]] attribute.
- cpgxiii 10mo ago
  Fwiw, unused-cast-to-void is a case that GCC and Clang ignore when using -Wno-old-style-cast, which is what most projects prohibiting C-style casts are going to be using (or whatever the equivalent their compiler provides).
deleted 10mo ago
[deleted]
time4tea 10mo ago
The point really was that the unused method parameter should in almost all cases be removed, not that some trick should be used to make it seem used, and this is the wrong trick!
- addaon 10mo ago
  Sometimes. But sometimes you have a set of functions that are called through function pointers that need the same signature, and one or more of them ignore some of the arguments. These days I’d spell that __attribute__((unused)); but it’s a perfectly reasonable case.
- bluGill 10mo ago
  #if otherbuild dosomething(param); #endif the above type of thing happens once in a while. nos the paramater is needed but the normal build doesn't use it

unwind 10mo ago

For C, the proper/expected/standard way to reference a variable without accessing it is a cast to void: (void) a; I'm sure there are commonly-implemented compiler extensions, but this is the normal/native way and should always work.

amluto 10mo ago
Not if you use GCC. https://godbolt.org/z/zYdc9ej88 https://godbolt.org/z/zYdc9ej88 clang gets this right.
- comex 10mo ago
  It does work in GCC to suppress unused variable warnings. Just not for function calls I guess.
  - cminmin 10mo ago
    __attribute__((maybe_unused)) or [[maybe_unused]] or such things (dependin on ur spec version i guess?) can be used not to disable a whole line of errors.
- Am4TIfIsER0ppos 10mo ago
  You've defined that function with an attribute saying not to ignore the returned value. Is it right to explicitly silence an explicit warning?
  - MathMonkeyMan 10mo ago
    Sometimes. For example, you might be setting a non-crucial option on a socket, and if it fails you don't even care to log the fact (maybe the logging would be too expensive), so you just ignore the return value of whatever library is wrapping setsockopt.
  - amluto 10mo ago
    I want some defined way to tell the compiler that I am intentionally ignoring the result. I encounter this when trying to do best-effort logging in a failure path. I call some function to log and error and maybe it fails. If it does, what, exactly, am I going to do about it? Log harder?

ivanjermakov 10mo ago

Zig makes it explicit with _ = a; And you would encounter it quite often because unused variable is a compilation error: https://github.com/ziglang/zig/issues/335 https://github.com/ziglang/zig/issues/335

ErroneousBosh 10mo ago
Golang is exactly the same. It's extremely annoying until it's suddenly very useful and has prevented you doing something unintended.
- bluecalm 10mo ago
  I fail to see how a warning doesn't achieve the same thing while allowing you to iterate faster. Unless you're working with barbarians who commit code that complies with warnings to your repo and there is 0 discipline to stop them.
  - treyd 10mo ago
    You're not supposed to question the wisdom of the Go developers. They had a very good reason for making unused variables be an unconfigurable hard error, and they don't need to rigorously justify it.
    - FieryMechanic 10mo ago
      Warnings are often ignored by developers unless you specifically force warnings to be compile errors (you can do this in most compiler). I work on TypeScript/C# code-bases and unless you force people to tidy up unused imports/using and variables, people will just leave them there. This BTW can cause issues with dependency chains and cause odd compile issues as a result.
      - account42 10mo ago
        > Warnings are often ignored by developers unless you specifically force warnings to be compile errors (you can do this in most compiler). Not my experience. Find better managers.

binary132 10mo ago

It’s very weird how none of the sibling comments understood what it were saying is wrong with this.

binary132 10mo ago
Erm, sorry about the weird typo. Didn’t notice. Can’t edit now.

tialaramex 10mo ago

Studies have looked at MISRA, I'm not aware of any for the JSF guidelines. For MISRA there's a mix, some of the rules seem to be effective (fewer defects in compliant software), some are the opposite (code which obeys these rules is more likely to have defects) and some were irrelevant. Notably this document is from 2005. So that's after C++ was standardized but before their second bite of that particular cherry and twenty years before its author, Bjarne Stroustrup suddenly decides after years of insisting that C++ dialects are a terrible idea and will never be endorsed by the language committee, that in fact dialects (now named "profiles") are the magic ingredient to fix the festering problems with the language. While Laurie's video is fun, I too am sceptical about the value of style guides, which is what these are. "TABS shall be avoided" or "Letters in function names shall be lowercase" isn't because somebody's aeroplane fell out of the sky - it's due to using a style Bjarne doesn't like.

writtiewrat 10mo ago
[flagged]
- tialaramex 10mo ago
  "No semantic effect" is one of those recurring C++ tropes like the "subset of a superset" or "trading performance for safety" that I think even its defenders ought to call bullshit on. The insistence on "No semantic effect" for attributes has poisoned them badly, and the choice to just ignore the semantic implications for Bjarne's C++ 20 Concepts makes this a poor substitute for the concepts feature as once imagined at the start of the century. I doubt I can satisfy you as to whether I'm somehow a paid evangelist, I remember I got a free meal once for contributing to the OSM project, and I bet if I dig further I can find some other occasion that, if you spin it hard enough can be justified as "payment" for my opinion that Rust is a good language. There was a nice lady giving our free cookies at the anti-racist counter-protests the other week, maybe she once met a guy who worked for an outfit which was contracted to print a Rust book? I sense you may own a corkboard and a lot of red string.
  - vlovich123 10mo ago

jjmarr 10mo ago

An unused parameter should be commented out.

MobiusHorizons 10mo ago
Unless it’s there to conform to an interface
- jjmarr 10mo ago
  Especially if it's there to conform to an interface. You can comment out the variable name and leave the type.

y1n0 10mo ago

The standards don't remove the need for code review. In fact they provide a standard to be used in code review. Anything you can automate is nice, but when you have exceptions to rules that say "Exception, if there's no reasonable way to do X then Y is acceptable" isn't really something you can codify into static analysis.

deleted 10mo ago

[deleted]

jojobas 10mo ago

Isn't it inevitable for some cases of inheritance? A superclass does something basic and doesn't need all parameters, child classes require additional ones.

platinumrad 10mo ago

I've (unfortunately) written plenty of "safety critical" code professionally and coding standards definitely have a negative effect overall. The thing keeping planes from falling out of the sky is careful design, which in practice means fail-safes, watchdogs, redundancy, and most-importantly, requirements that aren't overly ambitious. While maybe 10% of rules are sensible, these sensible rules also tend to be blindingly obvious, or at least table stakes on embedded systems (e.g. don't try to allocate on a system which probably doesn't have a full libc in the first place).

dilyevsky 10mo ago
Many coding standards rules have nothing to do with correctness and everything to do with things like readability and reducing cognitive load (“which style should I use here?”)

qart 10mo ago

You're right. MISRA is a cult. Actual studies[1][2] have shown many of their rules to be harmful rather than helpful. I have worked in multiple safety-critical industries. MISRA is almost always enforced by bureaucrats who don't understand source code at all, or by senior developers who rose up ranks as code monkeys. One such manager was impressed with Matlab because Matlab-generated C code was always MISRA compliant, whereas the code my company was giving them had violations. Never mind the fact that every function of the generated, compliant code had variables like tmp01, tmp02, tmp03, etc. There are many areas of software where bureaucracy requires MISRA compliance, but that aren't really safety-critical. The code is a hot mess. There are other areas that require MISRA compliance and the domain is actually safety-critical (e.g. automotive software). Here, the saving grace is (1) low complexity of each CPU's codebase and (2) extensive testing. To people who want actual safety, security, portability, I tell them to learn from examples set by the Linux kernel, SQLite, OpenSSL, FFMpeg, etc. Modern linters (even free ones) are actually valuable compared to MISRA compliance checkers. [1] https://ieeexplore.ieee.org/abstract/document/4658076 https://ieeexplore.ieee.org/abstract/document/4658076 [2] https://repository.tudelft.nl/record/uuid:646de5ba-eee8-4ec8-8bbc-2c188e1847ea https://repository.tudelft.nl/record/uuid:646de5ba-eee8-4ec8...

sam_bristow 10mo ago
One key point that people overlook with that paper is that they were applying the coding standards retroactively. Taking an existing codebase, running compliance tools, and trying to fix the issues which were flagged. I think they correctly identified the issue with this approach in that you have all the risks of introducing defects as part of reworking the existing code. I don't think they have much empirical evidence for the case where coding standards were applied from the beginning of a project. In my opinion, the MISRA C++ 2023 revision is a massive improvement over the 2008 edition. It was a major rethink and has a lot more generally useful guidance. Either way, you need to tailor the standards to your project. Even the MISRA standards authors agree: """ Blind adherence to the letter without understanding is pointless. Anyone who stipulates 100% MISRA-C coverage with no deviations does not understand what the are asking for. In my opionion they should be taken out and... well... Just taken out. - Chris Hill, Member of MISRA C Working Group (MISRA Matters Column, MTE, June 2012 """