Sure. And if you do that, you do not rely on a specific internal representation and all is well.
Which certainly violates MISRA rule 10 then: "Sections of code should not be 'commented out'." ;)
The interrupt handler was no problem for the self-written emulator. But that the two different compilers decided to count the bits from different directions, was.
Vinzent.
-- A C program is like a fast dance on a newly waxed dance floor by people carrying razors. -- Waldi Ravens
In that case, just use different header files, and some Makefile tricks :)
In message , D Yuniskis writes
Many want MISRA compliance.
Sounds completely unethical and unprofessional to me.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
There are groups/individuals in every industry that aspire to create/impose "standards" on the work performed *in*/for that industry. Most appear to be motivated by "noble causes". They all suffer from trivializing what is a complex problem.
I've seen movements to make engineers legally *liable* for the consequences of their designs ("Sure! And when do I get veto power over MY BOSS??"). I've seen folks insist that only "qualified" individuals write the code ("So, does this require a certain type of education? A certain level of intelligence?").
When the first MISRA release came out, a client waved it under my nose AS IF this would make the code I was about to write for him better -- *magically*. In the time it took me to skim the document (over lunch), I was able to show him that:
- much of it falls under the category of "don't use undefined or implementation-defined behaviors"
- some things were inconsistent ("test error values returned by functions" -- but *don't* use errno??)
- some things were crippling ("break" and "continue" -phobia!)
- some of it was just *silly* (the dreaded '$' character and the *sinister* "register" qualifier -- not to mention the worrisome *comma* operator!)
Much of the code I wrote last week would complain because of my liberal use of offsetof()! :<
Needless to say, he dropped the compliance requirement, I've heard of no deaths/injuries/recalls associated with the product. In fact, I've not had a single bug-fix request for it, either ("bug fixes" are "free" and immediate -- a *practical* way to keep pressure on the developer to provide quality code)
[apologies if I have misremembered any of this and/or if changes have been made in the years since this event] *Personally*, I abhor "closed" and "for pay" standards -- if what you have is so wonderful (and really little more than a piece of electronic paper), why horde it?How so? By giving the client what he claims to *want*? "Here, hire a team of (fill-in-the-blank) experts. Have them pour over the code for many man years. Let them convince you the code I've delivered is 100.00000000000% (fill-in-the-blank) compliant. Go to bed with peace of mind *hoping* that you really have a safe/secure/robust/'whatever' product/system (because that's what you *think* this compliance is giving you)"
These sorts of "Rules" try to make "better coders" out of run-of-the-mill coders by artificially imposing constraints on *how* they do *what* they do. But, they just shift attention to "silencing compiler warnings" instead of rethinking what they might be "doing wrong".
"Aw, crap! The compiler says I have two 'return' statements in this function. Now I have to rewrite the damn thing so there is only *one*... (regardless of how inappropriate that may be for this piece of code)"
It's the "Just Say No" (to drugs) mentality -- as if a catchy saying will solve the problem. The hope/delusion that you can (effectively) *LEGISLATE* quality, etc. Spend your resources hiring and training better staff so they design *in* quality from the start.
By far, the best environments I've found are those in which peer pressure (*not* "competition") inspires you to produce a quality product. Those in which "compliance" is pushed down "from above" end up fostering CYA behavior: "The code passed the compliance suite! It's not *my* fault..."
MISRA is not about making the code better. MISRA is about eliminating common sources of errors ("common" as in "statistically proven", which OTOH doesn't mean there aren't any other or that such requirements do not lead to other sources of errors ("others" as in "individually proven").
That said, I certainly doubt that obeying the rules of MISRA accomplished anything for someone who knows what s/hes doing. But that's also an individual perception, of course, not a statistically proven one.
Vinzent.
-- A C program is like a fast dance on a newly waxed dance floor by people carrying razors. -- Waldi Ravens
Correct. But, anyone "skilled in the art" *should* already know most of the issues that MISRA tries to address (replace "MISRA" with damn near any other "standard").
I contend that adopting these sorts of "standards" and the imperatives they impose ends up focusing attention on trivialities -- attention that should, instead, be focused on *bigger* issues.
It's the same sort of mentality that seeks to impose "style guidelines" on code in an attempt to make it more readable, maintainable, etc. People end up working to appease the Standard's God instead of focusing on the product they are preparing.
[this comes back to my assertion that "rules" should always be GUIDELINES. There's a big difference between a compiler offering reminders/suggestions -- "missing else", etc. -- to help catch problems. It's another thing entirely to require/prohibit certain things for fear they *might* cause problems.]But it (and similar "standards") can be counterproductive by forcing implementations to take "unnatural" forms. For example, I often wrap a section of code in a do-while(1) and liberally "break" out of that control structure (for error conditions, etc.). MISRA tells me this is "prohibited". So, I am now forced to contort the code to comply with this *arbitrary* prohibition just in case I might not be smart enough to use it properly?
Should we *ban* division because folks forget to test the denominator for zero? Should we *ban* "==" because folks fail to implement fuzzy equality tests for floats? Should we *ban* the use of the value "10" because some might consider it 10r10 while others consider it 10r2, 10r8 or 10r16? (or, perhaps we should ban all non-decimal radix? or, force all constants to explicitly declare their radix *and* data type -- is 50,000 a long or an int?)
Do you assume your staff are *competent* and provide them with tools to assist them in the performance of their duties? Or, do you assume they are INcompetent and impose a policeman/regulator to watch over them and scold them each time they do something "unexpected"?
Spend your resources ($$) on improving the quality of your staff. That's something that will benefit you in other ways that things like artificial "standards" can *never* address.
Over the years, I've found that "coding" is the *least* important of the aspects of product development. By far, proper *specification* and *testing* will result in a higher quality product (by *any* measure of "quality") than attempts to micromanage the "coding". (e.g., I budget 40% of my time for specification/design and 40% for testing/verification/validation... so "coding" takes a scant 20% of the effort. IMO, energy spent trying to improve that has far less impact on the result than improvements in this other "80%").
YMMV, of course.
Not /all/ suffer from trivializing complex problems. Just as many suffer equally from complicating trivial problems.
As far as I am concerned, a set of rules or definitions is not a standard unless it is well-maintained by a reputable body, freely available to view by anyone who wants it, freely implementable by anyone who wants to, represents a real and practical document that is widely followed, and adapts as required by its users, and modern developments. Without that, it's just a set of private rules for a particular club. That's fine in itself - private rules have lots of uses. But it is not a standard.
I have an even lower opinion of those who call their club rules "open standards" and yet still charge vast amounts to sell you a pseudo-pdf file that you can't use properly.
I understand that it costs a lot of money to produce such a set of rules, and that not everything can be state-sponsored even if it is for the greater good. But there are plenty of ways to make money from such an endeavour - charge for certification or the use of logos, sell printed books, provide courses and training, consultancy fees, compliance-checking software, etc.
You'll hear that a lot, regarding the code itself, the methodology used to write it, and the development tools to compile it. Some people think it is more important for a compiler to have passed a particular certification suite than to be correct - because then you can use that certification as a defence in court if you get sued.
The same can be said of the language gods trying to design the capacity for "error" (?) out of a language. Eventually, you end up with a language that isn't useful for anything other than academia :>
Educate; don't Legislate (impose).
+42
Or, hope for the benevolence of "key players" in those industries to underwrite all or part of their efforts. Things like Standards are so tenuous that you have to be wary that The Industry might just pick up and head off in a different direction regardless of your concern/interests.
The problem with "paid" organizations promoting/sponsoring things like this is they tend to be self-perpetuating. They have a vested interest in "their" Standard. So, the biological organisms involved in it have a *huge* stake -- their SALARIES!
By comparison, if you inspire people to take *personal* ownership of their product, they actually *care* about what they are producing and *want* it to work/be better, etc.
Abrogating some/any portion of your "ownership" of a product leaves you exposed to whatever "deficiencies" that other organization brings to the table (i.e., what if their quality isn;t up to par? what if they have made a mistake? etc.).
You can never protect completely against litigation (or stupidity!). So, you do some *reasonable* amount of "due diligence" and hope for the best. It's folly to try to design a hammer that *can't* be used to hit your own foot... or a wood chisel that can't be used to cut aluminum gutters.
OTOH, it costs very little to provide written warnings against these sorts of things...
Coding standards misra and others do a lot to make big projects much more reliable. They tend to force people to use clear statements devoid of the kind of one of programming tricks that create debugging and application nightmares.
I have seen a lot of code written by many different people the best fastest and most easy to maintain code is simple and clear and let modern tools do there work.
misra is a low cost standard well worth the cost.
Regards,
-- Walter Banks Byte Craft Limited
I assume that you don't charge for the work you do for customers.
w..
No, absolutely not. That rule (now 2.4) specifically says that you should use #if or #ifdef ...#endif instead of commenting out using /* ... */.
-- Fredrik Östman
In message , David Brown writes
Then neither ISO C or C++ are a "Standard"
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In message , D Yuniskis writes
Then there are no standards you can rely on.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
By the definition I used, then that's correct. They come close, however. But until you can freely download the pdfs, and use google to search online html versions, it's not a full standard to me. I think it is absurd that so many millions of developers around the world rely on these "standards", yet have no simple and easy way to view them. Online versions, especially with an interactive comment / wiki setup, would be a huge boon to developers.
There are plenty of different business models for different types of work. I have no issues with standards developers making money out of their work (though I think state sponsorship of standards committees is a better model in many cases). I just think that a better way to make that money is by publishing the standards freely and spreading them as wide as possible, then selling services (trademark licensing, consultancy, certification, etc.).
Maybe I'm naive here, and the sums wouldn't work out in the end. But Misra charge £10 for their pdf - it's absurd. Give it out free, and charge £100 for a Misra rule checker program.
They all have a VERY easy way to get the standards... they go and buy a copy of the PDF.
Incidentally the MISRA standards come closer than the ISO C and C++ standards by your definitions. For the ISO (and certainly the BSI parts of it) there is no requirement to have any qualifications or experience in the field of the standard.
BTW an on line wiki set up would be a complete disaster.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
No it is not. Why should MISRA not charge for the standard? DO you charge for your work?
IF it is free why charge for a rule checker program?
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
And will that pdf work on /my/ choice of pdf reader? Or is it one of these pseudo-pdf files that require a specific bug-ridden and security nightmare pdf reader with non-standard plugins and a specific OS? (I haven't got a copy of MISRA, so I don't know - but I know that applies to many other "standards" that are available on "pdf".)
MISRA are also closer in that £10 is a lot less than ISO charges for the C standards.
That depends on how it was done. I was thinking of the model used by PostgreSQL, such as here (look at the bottom of the page):
Registered community members can add comments to clarify the document, or to give hints or tips. The authors use these comments to improve later versions of the manual (and sometimes the software).
No idea. Probably Adobe and you can use any reader you with that is compliant.
MISRA can't do it for free for obvious reasons.
That is how MISRA works now. There is a forum for registered users to comment. They can not write to the document and "clarify" it as they will not have attended the meetings to know what was intended.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Coding *guidelines* can have the same effect -- without the "policeman". If your staff aren't competent enough to understand the costs and benefits associated with different language features, then you have bigger problems than a "standard" can fix.
The "cost" of an e-file isn't the issue. Rather, the cost of BLINDLY (i.e., following the "shalls" and "shoulds") adhering to it can be significant!
Standards cost a lot more than the "paper" they're written on. Someone has to codify an enforcement policy for your organization, put in place mechanisms to verify compliance, maintain any tools that are required for these activities, educate users as to why rules that obviously have significant coding consequences are BLINDLY enforced ("Yes, we value you as an employee... we just don't think you are smart enough to know when *to* use a goto/break/continue/etc. and when
*not* to -- so we'll just make it illegal to use them!"), determine (in some empirical manner) if the costs are being justified by productivity increases, etc.Or, go the DoD route -- impose heavy-handed "requirements" on the code, the coding *process*, specification, testing, etc. *That* sure seems to have worked out well for *them*, eh? ;-)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.