Chris Hills wrote:> In article <pKROh.17989$NK3.11439@newsfe6-win.ntli.net>, ChrisQuayle > <nospam@devnul.co.uk> writes > >> Colin Paul Gloster wrote: >> >>> The Ada standard is available for gratis. >> >> >> The point being ?. Would you expect to get a usefull book for nothing >> that someone has spent considerable time and effort to produce, or >> should everything be open source and free ?. Of course, including all >> your own work. >> >> Now that it's a sane price, have just downloaded the misra pdf version >> and am almost disappointed in that there's almost nothing that I can >> disagree with. Having seen so much controversy about it etc. In fact, >> it seems a bit lightweight, just good common sense practice that one >> would expect from any experienced embedded engineer. >> >> The C++ version should be quite interesting... > > > Hopefully by the end of the year. >and hopefully at the same price for pdf ?. It's in the whole industries interest for such ideas to be widely available and to become a common currency. Should be some fun and games though, the use of dynamic memory allocation stuff in C++, just to start with. Very subversive indeed :-)... Regards, Chris
shame on MISRA
Started by ●March 26, 2007
Reply by ●March 29, 20072007-03-29
Reply by ●March 29, 20072007-03-29
msg wrote:> Vladimir Vassilevsky wrote: >> >> Recently they showed me a case when the strict compliance to >> MISRA provoked the mistake: >> >> Original code: >> >> foobar() { >> u8 variable; >> variable = something; >> /* Explicit type conversion is required by MISRA. This is because >> of the C convention: result of any integer operation is int */ >> variable = (u8)(variable + 1); >> } >> >> Later, the code was modified. It was decided that variable should be u16. >> u16 variable; >> But this line was not changed: >> variable = (u8)(variable + 1); >> So here is a bug. No warnings.** Quote edited to reduce vertical space - cbf> > Why no warnings? What compiler? I frequently write for 'SCDE' > (Standard C Development Environment') on SVR4 (C 90) and also > port stuff developed by others on GCC which often produces lots > of warnings about "explicit cast required" for assignments and > logical comparisons which the original authors failed to qualify > with a cast. Evidently these things pass 'lint' and compile in > GCC with no warnings (even at a high warning level). Most > authors are dumbstruck by the need to explicitly cast (sometimes > even numeric constants).Any compiler. This shows the dangers of both using peculiar types (such as u8 and u16) and of casting. In general any cast is suspicious in C code. BTW, use of "variable++;" would have avoided it all. The original programmer was not up to the job. -- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> -- Posted via a free Usenet account from http://www.teranews.com
Reply by ●March 30, 20072007-03-30
CBFalconer wrote:> msg wrote: > I frequently write for 'SCDE' >>(Standard C Development Environment') on SVR4 (C 90) and also >>port stuff developed by others on GCC which often produces lots >>of warnings about "explicit cast required" for assignments and >>logical comparisons which the original authors failed to qualify >>with a cast. Evidently these things pass 'lint' and compile in >>GCC with no warnings (even at a high warning level). Most >>authors are dumbstruck by the need to explicitly cast (sometimes >>even numeric constants). > > > Any compiler. This shows the dangers of both using peculiar types > (such as u8 and u16) and of casting. In general any cast is > suspicious in C code.I should have provided an example. Here is a line from a popular opensource X10 automation package developed by its author on linux/gcc: typedef uint_t size_t; (unsigned int on both SVR4 and linux) size_t strlen (const char *s); void store_error_message ( char *message ); int space; ... if ( space < strlen(message) + 1 ) { No warnings under GCC. Note that strlen() returns size_t on linux as well as on SVR4. SCDE C compiler warns: "process.c", line 154: warning: semantics of "<" change in ANSI C; use explicit cast The line should have been written: if ( space < (int)strlen(message) + 1 ) { which eliminates the warnings. This particular program has many dozens of instances like this which needed fixing, as do so many other programs developed on linux/gcc. In this case as in most others the author is surprised by the warnings when reported to him. In more than a few instances, the lack of casts changes the logic of the statement and the result is not what the author intended. The astronomical ephemeris package 'XEphem' suffered from analysis errors due to this issue for example. Regards, Michael
Reply by ●March 30, 20072007-03-30
msg wrote:>... snip ...> > I should have provided an example. Here is a line from a popular > opensource X10 automation package developed by its author on > linux/gcc: > > typedef uint_t size_t; (unsigned int on both SVR4 and linux) > size_t strlen (const char *s); > void store_error_message ( char *message ); > int space; > ... > if ( space < strlen(message) + 1 ) { > > No warnings under GCC. Note that strlen() returns size_t > on linux as well as on SVR4.I disagree. space should have been defined as size_t. Then no casts, no warnings, no problems. -- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> -- Posted via a free Usenet account from http://www.teranews.com
Reply by ●March 30, 20072007-03-30
> Any compiler. This shows the dangers of both using peculiar types > (such as u8 and u16) and of casting. In general any cast is > suspicious in C code. > > BTW, use of "variable++;" would have avoided it all. The original > programmer was not up to the job. >The "original programmer" *was* writing a compiler for the PDP-11... -- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
Reply by ●March 30, 20072007-03-30
CBFalconer wrote:> msg wrote: > > ... snip ... > >>I should have provided an example. Here is a line from a popular >>opensource X10 automation package developed by its author on >>linux/gcc: >> >>typedef uint_t size_t; (unsigned int on both SVR4 and linux) >>size_t strlen (const char *s); >>void store_error_message ( char *message ); >>int space; >>... >> if ( space < strlen(message) + 1 ) { >> >>No warnings under GCC. Note that strlen() returns size_t >>on linux as well as on SVR4. > > > I disagree. space should have been defined as size_t. Then no > casts, no warnings, no problems.If only it were so simple; 'space' is used later on as an argument to library functions that take an 'int' so a cast would be needed at that point... Would your suggestion be to only use casts in assignments and not in comparisons? It is often difficult to avoid casts when accommodating existing libraries. Regards, Michael
Reply by ●March 30, 20072007-03-30
In article <xXWOh.25203$0Z1.6441@newsfe7-win.ntli.net>, ChrisQuayle <nospam@devnul.co.uk> writes>Chris Hills wrote: >> In article <pKROh.17989$NK3.11439@newsfe6-win.ntli.net>, ChrisQuayle >><nospam@devnul.co.uk> writes >> >>> Colin Paul Gloster wrote: >>> >>>> The Ada standard is available for gratis. >>> >>> >>> The point being ?. Would you expect to get a usefull book for >>>nothing that someone has spent considerable time and effort to >>>produce, or should everything be open source and free ?. Of course, >>>including all your own work. >>> >>> Now that it's a sane price, have just downloaded the misra pdf >>>version and am almost disappointed in that there's almost nothing >>>that I can disagree with. Having seen so much controversy about it >>>etc. In fact, it seems a bit lightweight, just good common sense >>>practice that one would expect from any experienced embedded engineer. >>> >>> The C++ version should be quite interesting... >> Hopefully by the end of the year. >> > >and hopefully at the same price for pdf ?. It's in the whole industries >interest for such ideas to be widely available and to become a common >currency.Yes but it won't be free. It costs quite a bit for produce a MISRA standard.>Should be some fun and games though, the use of dynamic memory >allocation stuff in C++, just to start with. Very subversive indeed >:-)...No Idea. I am not on the C++ panel I'm too busy. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●March 30, 20072007-03-30
"CBFalconer" <cbfalconer@yahoo.com> wrote in message news:460B8107.2575CE17@yahoo.com...> Tom Lucas wrote: >> "CBFalconer" <cbfalconer@yahoo.com> wrote in message >>> Dave Hansen wrote: >>> > ... snip ... >>>> >>>> My favorite, which is actually in use in code somewhere, is similar >>>> to >>>> digit = "0123456789ABCDEF"[value & 0x0F]; >>> >>> That is almost the only clear and portable way to convert into >>> hex. Routine. >> >> I've not seen this sort of thing before - what is the method called? >> I'd like to find out more about it. > > No name, just portable translation, where you can't count on ASCII > encoding. The same array can be used in both directions, if you > either up (or down) shift the input, or extend the array to > "0123456789abcdefABCDEF".That's a useful trick. Thanks for that.
Reply by ●March 30, 20072007-03-30
On Mar 30, 9:36 am, msg <msg@_cybertheque.org_> wrote:> CBFalconer wrote: > > msg wrote: > > > ... snip ... > > >>I should have provided an example. Here is a line from a popular > >>opensource X10 automation package developed by its author on > >>linux/gcc: > > >>typedef uint_t size_t; (unsigned int on both SVR4 and linux) > >>size_t strlen (const char *s); > >>void store_error_message ( char *message ); > >>int space; > >>... > >> if ( space < strlen(message) + 1 ) { > > >>No warnings under GCC. Note that strlen() returns size_t > >>on linux as well as on SVR4. > > > I disagree. space should have been defined as size_t. Then no > > casts, no warnings, no problems. > > If only it were so simple; 'space' is used later on as an argument > to library functions that take an 'int' so a cast would be needed > at that point... Would your suggestion be to only use casts > in assignments and not in comparisons? > > It is often difficult to avoid casts when accommodating existing > libraries.It is difficult to avoid casts, *if* you insist on doing explicit casting. If you don't mind standard C type conversions, explicit casting can be avoided in most circumstances. It's hard to say what's safer. Like Vladimir showed, an explicit cast can cause problems when the variable type is changed at a later stage. Also, there's a risk that inexperienced or lazy programmers get in the habit of inserting casts to get rid of compiler warnings, rather than fixing an underlying problem, such as types that are incompatible to begin with. Take your example: if ( space < (int) strlen(message) + 1 ) What if strlen returns a size_t, which is defined as a 32 bit 'unsigned long', space is defined as an 16 bit 'int', and your 'message' happens to be more than 32K ? Without the cast, 'space' would get an implicit promotion to 'unsigned long', and the comparison would still have worked (assuming 'space' is never negative).
Reply by ●March 30, 20072007-03-30
Op Thu, 29 Mar 2007 16:48:48 +0200 schreef Vladimir Vassilevsky = <antispam_bogus@hotmail.com>:> u8 variable; > variable =3D (u8)(variable + 1); > > u16 variable; > variable =3D (u8)(variable + 1); > > So here is a bug. No warnings.That is why some C compilers (and some C-like languages/compilers too) = have the typeof operator. -- = Gemaakt met Opera's revolutionaire e-mailprogramma: = http://www.opera.com/mail/
