Diễn đàn game zombie

Unfortunately no one can be told what FluxBB is - you have to see it for yourself.

You are not logged in.

#1 2020-09-14 09:42:10

CarinCowan
Member
Registered: 2020-09-14
Posts: 1

Proposed Rule Changes for Embedded C Coding Standard

Home.
Bloggers    Michael Barr .
Nigel Jones.
Miro Samek.
Posts  by Category .
Newsletter Signup.
About Us.
Contact Us.
Log in.
.

Search for:                         « C’s goto Keyword: Should we Use It or Lose It

Proposed Rule Changes for Embedded C  Coding Standard .
Wednesday, June 20th, 2018 by Michael Barr      My book Embedded C  Coding Standard  began as an internal coding standard of a consulting company and was first published in 2008 by that company (Netrino).
In 2013, the book’s cover was given a new look and  the standard  became known as “Barr Group‘s Embedded C Coding Standard“.
A 2018 update to the book will be released soon and this will be the first time the substance of  the standard  has changed in over a decade.
The primary motivation for making changes is to better harmonize the rules with the MISRA-C Guidelines.

The older Barr Group standard made reference to MISRA C:2004

which was superseded by MISRA C:2012.
The few known direct conflicts between BARR-C:2013 and MISRA C (stemming from our earlier embrace of ISO C99) were  effectively  eliminated with their 2012 update.
But we wanted to do  more than just  remove those noted conflicts and push even further in our embrace of harmonization.
In a sentence, MISRA C is a safer subset of the C language plus a set guidelines for using what is left of the language more safely.
In about as many words, BARR-C is a style guide for the C language that reduces the number of defects introduced during the coding phase by increasing  readability  and portability.
It turns out there is quite a bit of value in combining rules from both standards.
For example, MISRA’s guidelines do not provide stylistic advice and applying BARR-C’s stylistic rules to the C subset further increases safety.
The rest of this post is a preview of the specific  rule changes  and additions we will make in BARR-C:2013.
(Omitted from this list are rules reworded simply for greater clarity.) Rule 1.1.d (new) The following rule will be added:  Preprocessor directive #define shall not be used to alter or rename any keyword or other aspect of the programming language.
Rule 1.6.b (new) The following rule will be added:  Conversion from a pointer to void to a pointer to another type shall be cast.
Rule 1.7.c (change) The earlier rule:  The goto keyword shall not be used.
will be replaced with:  It is a preferred practice to avoid all use of the goto keyword.
If goto is used it shall only jump to a label declared later and in the same or an enclosing block.
This is being done so that the BARR-C standard does not restrict uses of goto that are permissible under MISRA C.
Rule 1.7.d (change) The earlier rule:  The continue keyword shall not be used.
will be replaced with:  It is a preferred practice to avoid all use of the continue keyword.
This is being done so that the BARR-C standard does not restrict uses of continue that are permissible under MISRA C.
Rule 1.7.e (eliminated) There will no longer be any restriction on the use of the break keyword.
This is being done so that the BARR-C standard does not restrict uses of break that are permissible under MISRA C.
Rule 4.2.d (change) The earlier rule:  No header file shall contain a #include statement.
will be replaced with:  No public header file shall contain a #include of any private header file.
This is being done because apparently no one (other than me) actually valued the old rule.
???? Rule 5.1.c (new) The following rule will be added:  The name of all public data types shall be prefixed with their module name and an underscore.
Rule 5.4.b.v (new) The following rule will be added:  Always invoke the isfinite() macro to check that prior calculations have resulted in neither infinity nor NaN.
Rule 5.6.a (new) The following rule will be added:  Boolean variables shall be declared as type bool.
Rule 5.6.b (new) The following rule will be added:  Non-Boolean values shall be converted to Boolean via use of relational operators (e.g., < or !=), not via casts.
Rule 6.2.c (changed) The earlier rule:  All functions shall have just one exit point and it shall be at the bottom of the function.
That is, the keyword return shall appear a maximum of once.
will be replaced with:  It is a preferred practice that all functions shall have just one exit point and it shall be via a return at the bottom of the function.
Rule 6.3.b.iv (new) The following rule will be added:  Never include a transfer of control (e.g., return keyword).
Rule 7.1.n (new) The following rule will be added:  The names of all variables representing non-pointer handles for objects, e.g., file handles, shall begin with the letter ‘h’.
Rule 7.1.o (new) The following rule will be added:  In the case of a variable name requiring multiple of the above prefixes, the order of their inclusion before the first underscore shall be [g][p|pp][b|h].
Rule 7.2.c (new) The following rule will be added:  If project- or file-global variables are used, their definitions shall be grouped together and placed at the top of a source code file.
Rule 7.2.d (new) The following rule will be added:  Any pointer variable lacking an initial address shall be initialized to NULL.
Rule 8.2.a (changed) The earlier rule:  The shortest (measured in lines of code) of the if and else if clauses should be placed first.
will be replaced with:  It is a preferred practice that the shortest (measured in lines of code) of the if and else if clauses should be placed first.
Rule 8.3.c (new) The following rule will be added:  Any case designed to fall through to the next shall be commented to clearly explain the absence of the corresponding break.
Rule 8.5.b (new) The following rule will be added:  The C Standard Library functions abort(), exit(), and setjmp()/longjmp() shall not be used.
If you have questions about any of these draft changes or suggestions for better or other changes, please comment below.
Tags: bugs, embedded, firmware, reliability, safety, security, standards           This entry was posted       on Wednesday, June 20th, 2018 at 3:43 am   and is filed under Coding Standards.
You can follow any responses to this entry through the RSS 2.0 feed.
You can skip to the end and leave a response.
Pinging is currently not allowed.

16 Responses to “Proposed Rule Changes for Embedded C Coding Standard”

Luca Matteini          June 20, 2018 at 4:28 am     I like all the changes and additions but… well, as I coded over the years many (simple) multi tasking executives, the last new 8.5.b would not find my favor, somewhat.
I’ve mixed feelings.
However, time has passed and I’d say that every day fewer ones should be tempted by setjmp/longjmp more than they would by a “goto”.
At the same time, people in search for task/thread/fiber management go headlessness for RTOSes that not always shine for security too.
This remembers me nightmares of some software I had to revise in the 80s, in assembly of course, where the original developer jumped/branched all the time here and there, for “code reuse”(!)   Reply.
Jimmy Pedersen          June 20, 2018 at 5:50 am     These all sounds nice and addresses most the minor issues  (1.1.d, 1.7.c, 4.2.d, .

6.2.c) I had with the standard Thanks for your continued work with the standards   Reply

Ray Keefe          June 20, 2018 at 6:31 am     Seems like a reasonable step forward.
We do have one client who insisted we use setjmp()/longjmp() so that would not have been compliant.
We have a done a lot of MISRA compliant projects and they used a rule where you could only break a rule if there was a documented reason and it was signed off.
The equivalent of a quality system concession.
Can be done but has to be intentional, justified and approved.

Reply                             June 20

2018 at 8:11 am     Our standard describes a similar “Deviation Procedure” in the introductory material.
Reply.
Ben Sweet          June 20, 2018 at 7:22 am     Re: Rule 6.3.b.iv (new) The following rule will be added:     Never include a transfer of control (e.g., return keyword).
This statement seems like it is missing something, unless I am reading it incorrectly.
Never include a transfer of control … (in what.

A macro?) ~Ben ~~~~~~~~~~~~~~~~~~   Reply                             June 20

2018 at 8:10 am     The context is that all of the Rules in Section 6.3 relate to Function-Like Macros.
Reply.
Michael Simpson          June 20, 2018 at 7:24 am     It all sounds reasonable.
I do have a question about 4.2.d: is there a definition of a “private header file”.
Reply                             June 20, 2018 at 8:10 am     A public header file is one shared by two or more source code files.
A private header file is any other header file.
Reply.
Bob Paddock          June 20, 2018 at 7:28 am     “Rule 5.1.c (new) The following rule will be added: The name of all public data types shall be prefixed with their module name and an underscore.
” For clarity it should be explicit that the underscore is a suffix as in ‘Foo_’.
“Rule 7.1.n (new) The following rule will be added: The names of all variables representing non-pointer handles for objects, e.g., file handles, shall begin with the letter ‘h’.
” and “Rule 7.1.o (new) The following rule will be added: In the case of a variable name requiring multiple of the above prefixes, the order of their inclusion before the first underscore shall be [g][p|pp][b|h].” Need some examples in respect to 5.1.c.
Such as ‘gppbhFoo_’ (likely intent, violates 5.1.c), ‘Foogppbh_’ (yuck, yet compliant), ‘Foo_gppbh’ (Not compliant with 7.1.o).
Also should it not be [h|b][g][p|pp] in respect to 7.1.n.
Otherwise reorder these two rules.
I know I lost this argument long ago, I never agree with prefixed notation.
For exactly the above issues.
Destroys any sense of a sorted symbol table or map etc.
Suffixed notation avoids this and has other advantages that I’ve documented in my blog in the past.
“Rule 5.6.a (new) The following rule will be added: Boolean variables shall be declared as type bool.” ‘bool_t’ should also be an allowed type to match the format of.
“Rule 6.2.c (changed) The earlier rule: All functions shall have just one exit point and it shall be at the bottom of the function.
That is, the keyword return shall appear a maximum of once.
will be replaced with: It is a preferred practice that all functions shall have just one exit point and it shall be via a return at the bottom of the function.” “Rule 6.3.b.iv (new) The following rule will be added: Never include a transfer of control (e.g., return keyword).” Feels like a direct contradiction of 6.2.c.
I understand the intent, the interaction between the these two rules needs some work in the language.

The Barr Standard has been usable with Gimpel Lint in the past

Read VERY CAREFULLY the new license agreement with the newest versions.
I’ll expound on that in my blog.
Reply.
Andrew          June 20, 2018 at 11:14 am     I’m still not convinced by 4.2d) My view is that an include file should directly #include all necessary header files – this ensures that analysis (and build) is coherent, without a programmer having to guess what else is needed.
A header file that *assumes* prior inclusion of other header files is unhelpful… such documentation is often forgotten about.

Reply                   Daniel          June 22

2018 at 3:25 pm     Additionally, some IDEs with smart completion and/or syntax highlighting will only perform properly if the type definitions are available to it (by being #included).
I don’t think a coding standard should include rules that inhibit tools from doing static error checking.
Reply                             June 23, 2018 at 12:45 am     I’m not aware of anything in the old or new language of Rule 4.2.d that could prevent a static analysis tool from being able to see the declarations of types used in source files.
Ultimately, the pattern of #includes always has to support compilation.
Reply.
Dan Tebbs          June 20, 2018 at 12:01 pm     I love it.
With these changes I am 100% of accord.
Thanks for all your work on this.
Reply.
Brian Arnberg          June 28, 2018 at 12:51 pm     When this is finalized will you be updating your pc-lint configuration and providing that to the public.
Reply                             July 1, 2018 at 7:31 pm     Yes.
Reply.
Nick          July 12, 2018 at 12:10 pm     Direct assignment of pointer to void to a pointer of any other type is well defined.
The only reason I can think of for requiring a cast is to force us to talk about it by way of 1.6.a.
Is that correct.
If so then consider this: If we have a function that takes an argument of type pointer to void we have likely already documented that the function takes a pointer to void because it doesn’t care about the underlying type and operates on the data byte wise, word wise, or whatever.
Could a better rule be “don’t use pointers to void except for making data type agnostic interfaces”.
Reply.
Leave a Reply.
Click here to cancel reply.
Name (required)   Mail (will not be published) (required)   Website                                  Barr Code.
Michael Barr.
Michael Barr is an expert on the design of software-powered medical devices and other embedded computer systems.
(full bio).
Pages.
Contact Michael.
Links.
Embedded C Coding Standard.
Embedded Software Boot Camp.
Embedded Software Training in a Box.
Embedded Systems Experts.
Embedded Systems Glossary.
Expert Witness Resume.
My EETimes Column.
My LinkedIn Profile.
My Twitter Feed.
Recent Posts.
Proposed Rule Changes for Embedded C Coding Standard.
C’s goto Keyword: Should we Use It or Lose It.
The Rise of the Full Stack Developers.
Survey Says: The Commercial RTOS Business is Doomed.
C: The Immortal Programming Language.
Is it a Bug or an Error.
New BlueBorne Security Flaw Affects Embedded Systems Running Linux.
C’s strcpy_s(): C11’s More Secure Version of strcpy().
Did a Cyberattack Cause Recent Crashes of U.
S.
Naval Destroyers.
Cyberspats on the Internet of Things.
Recent Comments.
Nick  .

On Proposed Rule Changes for Embedded C Coding Standard

on Proposed Rule Changes for Embedded C Coding Standard.

Brian Arnberg  on Proposed Rule Changes for Embedded C Coding Standard

on Proposed Rule Changes for Embedded C Coding Standard.

Daniel  on Proposed Rule Changes for Embedded C Coding Standard

Tags.
architecture baltimore barrgroup bugs copyright delicious education embedded engineering ethics firmware india java linux motorhome netrino opensource outsourcing patents processors programming realtime reliability rss rtos safety security standards startups trac trademarks trends.
Categories.
Coding Standards (25).
Computer Security (5).
Efficient C/C++ (7).
Firmware Bugs (29).
Intellectual Property (4).
RTOS Multithreading (27).
Uncategorized (37).
Archives.
June 2018 (2).
May 2018 (1).
February 2018 (2).
January 2018 (1).
October 2017 (1).
August 2017 (2).
April 2017 (1).
March 2017 (1).
March 2015 (1).
April 2014 (1).
March 2014 (3).
January 2014 (1).
October 2013 (1).
June 2013 (1).
February 2013 (1).
December 2012 (1).
November 2012 (2).
April 2012 (1).
March 2012 (1).
January 2012 (1).
September 2011 (1).
August 2011 (1).
June 2011 (2).
May 2011 (2).
April 2011 (1).
March 2011 (4).
February 2011 (4).
January 2011 (1).
December 2010 (2).
November 2010 (6).
October 2010 (2).
September 2010 (2).
August 2010 (2).
March 2010 (5).
February 2010 (5).
January 2010 (5).
December 2009 (3).
November 2009 (4).
October 2009 (3).
September 2009 (4).
August 2009 (2).
July 2009 (1).
June 2009 (1).
May 2009 (1).
April 2009 (5).
March 2009 (9).
February 2009 (3).
January 2009 (4).
June 2008 (1).
April 2008 (3).
March 2008 (5).
February 2008 (5).
January 2008 (4).
December 2007 (2).
November 2007 (1).
September 2007 (2).
August 2007 (1).
July 2007 (2).
June 2007 (4).
May 2007 (2).
November 2006 (1).
October 2006 (2).
September 2006 (5).
March 2006 (1).
January 2006 (1).
December 2005 (1).
December 2003 (1).
November 2003 (1).
September 2003 (1).
July 2003 (1).
June 2003 (1).
May 2003 (1).
April 2003 (1).
March 2003 (1).
February 2003 (1).
January 2003 (1).
December 2002 (1).
November 2002 (1).
October 2002 (1).
September 2002 (1).
August 2002 (1).
July 2002 (1).
June 2002 (1).
April 2002 (1).
March 2002 (1).
February 2002 (1).
January 2002 (1).
December 2001 (1).
November 2001 (1).
October 2001 (1).
September 2001 (9).

Offline

Board footer

Powered by FluxBB