shame on MISRA
disi...@rootshell.be
// Misra warning: file scope static, used in one function
static u8 X;
static f(void)
{
// Misra warning: it is not correct to use block scope static
variable. define it at file scope
static u8 Y;
X = ++Y;
}
sample2 (another catch 22):
void f(void)
{
u8 X;
.... performing some calculations, that guarantee X<2
switch(X)
{
case 0: doSomething(); break;
case 1: SomethingElse(); break;
// choose between the following warning:
// 1. inaccessible default statement
// 2. case without default statement
default: assert(0); break;
}
}
sample3 (senseless code damage due to MISRA):
u8 *u8Ptr1,u8Ptr2;
u32 N;
.... some calculations
// Misra warning: performing pointer arithmetic
u8Ptr1 = u8Ptr2+N;
// The following replacement help us to decrease warning number
// No warning here! but this is semantically the same as above
according ISO & ANSI.
// It is exactly as (un)safe as the example above and generates the
same binary code:
u8Ptr1 = &u8Ptr2[N];
and many other examples - I don't remember them all.
finally, this is an excellent resume on MISRA stupidity:
http://www.knosof.co.uk/misracom.html
It is a set of rules, defined by not very clever people (especially
the older MISRA version) and used
by automotive software producers, because it looks nice for the
bureaucratic high-level managment.
please, for those who do not code using strict misra checker: do not
argue that MISRA is good. Without signifficant changes and
improvements to these rules, it is not more than annoying tool.
Compiler warnings of a good CC are far more useful to prevent bugs at
early stage development.
And do not wonder if you see buggy embedded software! A precious time
is spent every day to justify lots of senseless warnings.
Chris Hills
disi...@rootshell.be writes
>
>finally, this is an excellent resume on MISRA stupidity:
>http://www.knosof.co.uk/misracom.html
>
>It is a set of rules, defined by not very clever people (especially
The author of the link you cite was also involved in the first version
of MISRA-C and is taking part in MISRA-C++
>please, for those who do not code using strict misra checker: do not
>argue that MISRA is good. Without signifficant changes and
>improvements to these rules, it is not more than annoying tool.
>Compiler warnings of a good CC are far more useful to prevent bugs at
>early stage development.
And who are you to say this? You hide behind a fake email address.
Identify yourself, make the comments again .
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Paul E. Bennett
> finally, this is an excellent resume on MISRA stupidity:
> http://www.knosof.co.uk/misracom.html
>
> It is a set of rules, defined by not very clever people (especially
> the older MISRA version) and used
> by automotive software producers, because it looks nice for the
> bureaucratic high-level managment.
>
> please, for those who do not code using strict misra checker: do not
> argue that MISRA is good. Without signifficant changes and
> improvements to these rules, it is not more than annoying tool.
> Compiler warnings of a good CC are far more useful to prevent bugs at
> early stage development.
>
> And do not wonder if you see buggy embedded software! A precious time
> is spent every day to justify lots of senseless warnings.
I hope you are referring to the latest examples/code snippets released
(earlier this year I think) and not the snippets that came out with the
earlier version of the MISRA guidelines. Engineers should all be working to
current best practice and that means mindful of the latest and emergent
standards.
I notice that the link you provided was from 2005.
--
********************************************************************
Paul E. Bennett ....................<email://p...@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Pete Fenelon
>
> It is a set of rules, defined by not very clever people (especially
> the older MISRA version) and used
MISRA owes a lot to Les Hatton's work as described in "Safer C".
Les Hatton is *very* bright. But Les's vision got diluted more and
more (particularly in the first version of MISRA) by people who
perhaps didn't know the language anything like as well as he did.
pete
--
pe...@fenelon.com "how many clever men have called the sun a fool?"
Vladimir Vassilevsky
disi...@rootshell.be wrote:
What MISRA checker are you using?
> sample1.c (catch 22):
> // Misra warning: file scope static, used in one function
> static u8 X;
>
> static f(void)
> {
> // Misra warning: it is not correct to use block scope static
> variable. define it at file scope
> static u8 Y;
> X = ++Y;
> }
Yes, there is a lot of silly things like that in MISRA. It is quite
difficult to be 100% compliant.
> sample2 (another catch 22):
> void f(void)
> {
> u8 X;
> .... performing some calculations, that guarantee X<2
> switch(X)
> {
> case 0: doSomething(); break;
> case 1: SomethingElse(); break;
> // choose between the following warning:
> // 1. inaccessible default statement
> // 2. case without default statement
> default: assert(0); break;
> }
> }
Yes, this is correct. First of all, an integer should not be used as the
switch argument; switches should be used with enums only.
> sample3 (senseless code damage due to MISRA):
> u8 *u8Ptr1,u8Ptr2;
> u32 N;
> .... some calculations
>
> // Misra warning: performing pointer arithmetic
> u8Ptr1 = u8Ptr2+N;
Yes, this is correct. You should not modify, alias or copy the pointers.
Work with arrays and indexes only.
> // The following replacement help us to decrease warning number
> // No warning here! but this is semantically the same as above
> according ISO & ANSI.
> // It is exactly as (un)safe as the example above and generates the
> same binary code:
> u8Ptr1 = &u8Ptr2[N];
> and many other examples - I don't remember them all.
>
> finally, this is an excellent resume on MISRA stupidity:
> http://www.knosof.co.uk/misracom.html
So? Should we file the complaint to the UN?
> It is a set of rules, defined by not very clever people (especially
> the older MISRA version) and used
> by automotive software producers, because it looks nice for the
> bureaucratic high-level managment.
It is better then nothing, anyway.
> please, for those who do not code using strict misra checker: do not
> argue that MISRA is good.
I had to write MISRA compliant code, and yes, it is too restrictive and
very annoying at times. Nevertheless it does a good job on extirpating
the hackery.
Without signifficant changes and
> improvements to these rules, it is not more than annoying tool.
> Compiler warnings of a good CC are far more useful to prevent bugs at
> early stage development.
MISRA is not too bad. You just have to get used to it.
> And do not wonder if you see buggy embedded software!
Unfortunately, there is no replacement for the common sense, experience,
good taste and intelligence (Stroustrup).
> A precious time
> is spent every day to justify lots of senseless warnings.
If you are paid to write MISRA compliant code, you should write MISRA
compliant code. What is the problem?
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
Al Balmer
>And do not wonder if you see buggy embedded software! A precious time
>is spent every day to justify lots of senseless warnings.
If your job requires that you write MISRA-compliant code, I would
think you'd learn how to avoid the warnings and stop wasting precious
time.
--
Al Balmer
Sun City, AZ
Jack Klein
comp.arch.embedded:
...and even more so, PC Lint. With a modified version of its MISRA
rule set, to skip the more obnoxious MISRA rules.
> And do not wonder if you see buggy embedded software! A precious time
> is spent every day to justify lots of senseless warnings.
"Shame on MISRA" is far too strong a statement.
There are some MISRA rules that I consider useless. On the other
hand, there is a lot of good there. It is certainly better, as a
whole, than anything else I have ever seen, especially for safety
critical embedded systems.
And the 2004 version has some improvements, although I have never
specifically tried to analyze all of the differences between the two.
I view the MISRA standard like I view the C standard. Both are
efforts by a committee of people, and both have done a remarkably good
job overall, but neither is perfect. Nothing generated by human
beings is.
I have seen a fair number of articles criticizing the shortcomings of
MISRA C, but I have yet to see any of the critics offering an improved
alternative.
Perhaps it is just because I am the one who sets the embedded C coding
guidelines for my organization, so I get to decide which of the MISRA
rules we embrace and which we ignore.
Note to Chris Hills: I am not now, and never have, hidden behind a
fake email address on usenet.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Dan Henry
=== Snipped previous samples ===
>sample3 (senseless code damage due to MISRA):
>u8 *u8Ptr1,u8Ptr2;
>u32 N;
>.... some calculations
>
>// Misra warning: performing pointer arithmetic
>u8Ptr1 = u8Ptr2+N;
We don't know what u8 is, but nevertheless, u8Ptr1 is a pointer to a
u8 and u8Ptr2 is a u8. The warning "performing pointer arithmetic"
doesn't seem to apply. In a non-MISRA context, I would have expected
to see a warning about type incompatibility.
--
Dan Henry
Dan Henry
=== Snipped previous samples ===
>sample3 (senseless code damage due to MISRA):
>u8 *u8Ptr1,u8Ptr2;
>u32 N;
>.... some calculations
>
>// Misra warning: performing pointer arithmetic
>u8Ptr1 = u8Ptr2+N;
We don't know what u8 is, but nevertheless, u8Ptr1 is a pointer to a
Chris Hills
<pe...@stratos.fenelon.com> writes
>disi...@rootshell.be wrote:
>>
>> It is a set of rules, defined by not very clever people (especially
>> the older MISRA version) and used
>
>MISRA owes a lot to Les Hatton's work as described in "Safer C".
>Les Hatton is *very* bright. But Les's vision got diluted more and
>more (particularly in the first version of MISRA) by people who
>perhaps didn't know the language anything like as well as he did.
The other people involved in the background were also quite clever.
Three of them came from one place.... The author of the link the OP
cited was one of the three.
Chris Hills
<jack...@spamcop.net> writes
>> is spent every day to justify lots of senseless warnings.
>
>"Shame on MISRA" is far too strong a statement.
>
>There are some MISRA rules that I consider useless. On the other
>hand, there is a lot of good there. It is certainly better, as a
>whole, than anything else I have ever seen, especially for safety
>critical embedded systems.
Thanks. It is not perfect but we hope better than most other options.
I note that the JSF++ was based on MISRA-C
>I view the MISRA standard like I view the C standard. Both are
>efforts by a committee of people, and both have done a remarkably good
>job overall, but neither is perfect. Nothing generated by human
>beings is.
There will be a TC and example suite soon and a MISRA-C V3 in a few
years. Hopefully it will have the same level of improvements between 2 &
3 as 1 & 2
>I have seen a fair number of articles criticizing the shortcomings of
>MISRA C, but I have yet to see any of the critics offering an improved
>alternative.
Others have tried but it takes a LOT of work.
The MISRA team meet for 2 full days every 12 weeks and do other MISRA
work in between. Between us we have access to something like 10 major C
code analysis tools for testing the rules as well as many decades of
experience of real work problems and projects. Mostly in high integrity
and safety critical systems.
The review team is a couple of hundred strong and includes SAE, JSAE,
JAMA, HIS etc
>Perhaps it is just because I am the one who sets the embedded C coding
>guidelines for my organization, so I get to decide which of the MISRA
>rules we embrace and which we ignore.
That is fine They are there for guidance. I have always said "You can
deviate all you want as long as you can stand by your deviations a few
years down the line in a court of law ." That usually makes people
think... which is the best we can hope for.
>Note to Chris Hills: I am not now, and never have, hidden behind a
>fake email address on usenet.
Never said you were I was addressing the comment to
disi...@rootshell.be
Arlet
wrote:
> > sample3 (senseless code damage due to MISRA):
> > u8 *u8Ptr1,u8Ptr2;
> > u32 N;
> > .... some calculations
>
> > // Misra warning: performing pointer arithmetic
> > u8Ptr1 = u8Ptr2+N;
>
> Yes, this is correct. You should not modify, alias or copy the pointers.
> Work with arrays and indexes only.
The point of the OP was that you can trivially rewrite the offending
expression by the following, equally unsafe code, and avoid the
warning:
u8Ptr1 = &u8Ptr2[N];
Or one could even avoid pointers altogether, and write something like
this, which can be as unsafe as the previous:
N = /* complicated expression */
a = u8Ptr2[N];
The bigger issue is that basically *any* random C program can be
converted into an equivalent program that complies with MISRA rules
(or any other set of similar rules, for that matter). This conversion
process can even be done fully automatically by a suitable tool. Of
course, simply rewriting code into a different syntactic form does
not, by itself, increase the safety.
In the end, the programmer must not just follow the rules, but also
understand the reasoning behind them, and must apply the same
philosophy to the rest of his work. It should not come as a surprise
that a set of guidelines can be subverted by a sufficiently motivated
person.
Vladimir Vassilevsky
Arlet wrote:
> The bigger issue is that basically *any* random C program can be
> converted into an equivalent program that complies with MISRA rules
> (or any other set of similar rules, for that matter). This conversion
> process can even be done fully automatically by a suitable tool. Of
> course, simply rewriting code into a different syntactic form does
> not, by itself, increase the safety.
Very good point.
> In the end, the programmer must not just follow the rules, but also
> understand the reasoning behind them, and must apply the same
> philosophy to the rest of his work.
MISRA comes with clear and straightforward guideline documentation. This
documentation explains the reasoning behind every rule, and suggests the
whole methodology of the development. Most of the MISRA philosophy is
just the common sense and good software development practice.
> It should not come as a surprise
> that a set of guidelines can be subverted by a sufficiently motivated
> person.
In this case, MISRA acts as the disciplinary tool forcing the stubborn
donkeys to comply to the letter of the rules at the least.
John Perry
> ...
>
> The bigger issue is that basically *any* random C program can be
> converted into an equivalent program that complies with MISRA rules
> (or any other set of similar rules, for that matter). This conversion
> process can even be done fully automatically by a suitable tool. Of
> course, simply rewriting code into a different syntactic form does
> not, by itself, increase the safety.
>
...and the fault with MISRA is...?
> In the end, the programmer must not just follow the rules, but also
> understand the reasoning behind them, and must apply the same
> philosophy to the rest of his work. It should not come as a surprise
> that a set of guidelines can be subverted by a sufficiently motivated
> person.
...But the point of MISRA and such is not to be proof against the bad
guys, but to rein in the prima donnas and "clever" programmers who think
it's cool to write obscure code that does strange things just because
they think they can, and the even worse fools who "don't want their
creativity limited".
(that's a particular thorn in my side right now, having to modify code
from one these idiots).
John Perry
Pete Fenelon
> The other people involved in the background were also quite clever.
> Three of them came from one place.... The author of the link the OP
> cited was one of the three.
Indeed, Derek's company does some excellent work and Derek writes some
very trenchant and elegant papers.
I was referring more to some of the end-user companies involved in
MISRA; I've dealt with some of the automotive companies involved and
been less than 100% impressed with their grasp of the subtleties.
Chris Hills
Arlet <usen...@c-scape.nl> writes
>In the end, the programmer must not just follow the rules, but also
>understand the reasoning behind them, and must apply the same
>philosophy to the rest of his work.
I hope so. That is the intention
> It should not come as a surprise
>that a set of guidelines can be subverted by a sufficiently motivated
>person.
I know and sadly that is the case with the MISRA rules too. We see
people trying to comply with the letter whilst subverting the spirit.
Chris Hills
<pe...@stratos.fenelon.com> writes
>Chris Hills <ch...@phaedsys.org> wrote:
>> The other people involved in the background were also quite clever.
>> Three of them came from one place.... The author of the link the OP
>> cited was one of the three.
>
>Indeed, Derek's company does some excellent work and Derek writes some
>very trenchant and elegant papers.
Derek is a one man outfit. He was working somewhere else previously
where some of the other major contributors also came from
>I was referring more to some of the end-user companies involved in
>MISRA;
Such as?
> I've dealt with some of the automotive companies involved and
>been less than 100% impressed with their grasp of the subtleties.
Such as?
Chris Hills
writes
You might think that I could not possibly comment
See http://www.phaedsys.demon.co.uk/chris/mistrayc/MISTRAYC.pdf
for a REAL programmers guide for people who do not want their creativity
limited.
Paul E. Bennett
> You might think that I could not possibly comment
>
>
> See http://www.phaedsys.demon.co.uk/chris/mistrayc/MISTRAYC.pdf
> for a REAL programmers guide for people who do not want their creativity
> limited.
Except that the file could not be opened (even from the web page above it).
Chris Hills
<p...@amleth.demon.co.uk> writes
>Chris Hills wrote:
>
>> You might think that I could not possibly comment
>>
>>
>> See http://www.phaedsys.demon.co.uk/chris/mistrayc/MISTRAYC.pdf
>> for a REAL programmers guide for people who do not want their creativity
>> limited.
>
>Except that the file could not be opened (even from the web page above it).
>
Very strange as I cut and pasted the link from the web browser....
Can any one else see the pdf OK?
Grant Edwards
>>> See http://www.phaedsys.demon.co.uk/chris/mistrayc/MISTRAYC.pdf
>>> for a REAL programmers guide for people who do not want their creativity
>>> limited.
>>
>>Except that the file could not be opened (even from the web page above it).
>
> Very strange as I cut and pasted the link from the web browser....
> Can any one else see the pdf OK?
Worked fine for me.
--
Grant Edwards grante Yow! NOT fucking!! Also
at not a PACKAGE of LOOSE-LEAF
visi.com PAPER!!
Steve at fivetrees
news:TTyuItLY...@phaedsys.demon.co.uk...
> In article <eubpe9$538$1$830f...@news.demon.co.uk>, Paul E. Bennett
> <p...@amleth.demon.co.uk> writes
>>Chris Hills wrote:
>>
>>> You might think that I could not possibly comment
>>>
>>>
>>> See http://www.phaedsys.demon.co.uk/chris/mistrayc/MISTRAYC.pdf
>>> for a REAL programmers guide for people who do not want their creativity
>>> limited.
>>
>>Except that the file could not be opened (even from the web page above
>>it).
>>
>
> Very strange as I cut and pasted the link from the web browser....
> Can any one else see the pdf OK?
Looks fine here. (Apart from some of the spelling ;) ;).)
disi...@rootshell.be
> difficult to be 100% compliant.
100% MISRA compliance. But unfortunately it is expected from me.
> Yes, this is correct. First of all, an integer should not be used as the
> switch argument; switches should be used with enums only.
It is just an example. The same example applies to enumerated type.
> Yes, this is correct. You should not modify, alias or copy the pointers.
> Work with arrays and indexes only.
a = &x[i] is absolutely equivalent to a=x+i (assuming i is an integer
and a&x are pointers of the same type). It is not a big problem but it
is a senseless warning. And a = x+i makes more sense in some
circumstances. I acknowledge that this is my personal opinion and
maybe it is not entirely correct, and it is finally minor problem - I
can always use a=&x[i].
> It is better then nothing, anyway.
I agree.
> I had to write MISRA compliant code, and yes, it is too restrictive and
> very annoying at times. Nevertheless it does a good job on extirpating
> the hackery.
So in order to stop hackery we should code in BASIC ?
> MISRA is not too bad. You just have to get used to it.
10x, unfotunately I USE it.
> Unfortunately, there is no replacement for the common sense, experience,
> good taste and intelligence (Stroustrup).
yes, I acknowledge - I am stupid too.
> If you are paid to write MISRA compliant code, you should write MISRA
> compliant code. What is the problem?
If I'm paid to be a hooker, it will be a problem for me to be a hooker.
disi...@rootshell.be
> I hope you are referring to the latest examples/code snippets released
> (earlier this year I think) and not the snippets that came out with the
> earlier version of the MISRA guidelines. Engineers should all be working to
> current best practice and that means mindful of the latest and emergent
> standards.
>
> I notice that the link you provided was from 2005.
Correct - I have to clarify that I refer to old MISRA rules. I am not
aware of latest MISRA rules. They are not freely available and I have
not access to latest rules but I sincerely hope that latest rules are
a lot better.
disi...@rootshell.be
> think you'd learn how to avoid the warnings and stop wasting precious
> time.
my employer is not clean.
And also clients of my employer think that _every_ MISRA deviation is
dangerous and terrible. And what I claim is that MISRA people are
guilty about this situation. It is not about me - I can always find
another job. It is about many poor embedded developers all over the
world.
Vladimir Vassilevsky
disi...@rootshell.be wrote:
>>I had to write MISRA compliant code, and yes, it is too restrictive and
>>very annoying at times. Nevertheless it does a good job on extirpating
>>the hackery.
>
> So in order to stop hackery we should code in BASIC ?
Actually, it would be good to code the embedded stuff in Ada, Java or at
least C#. However, hackery is a not a technical problem. The
non-technical problems can't be avoided by any technical means. You may
think of MISRA as something like a marching drill in the army. Albeit it
is useless from the combat prospective, it makes everyone disciplined
and compliant.
>>If you are paid to write MISRA compliant code, you should write MISRA
>>compliant code. What is the problem?
>
> If I'm paid to be a hooker, it will be a problem for me to be a hooker.
>
Not really, in the wide sense. You are leasing your head and hands, and
a hooker is leasing the other body members. The top class hooker is
called a celeb, the difference is only in the amount of many paid.
VLV
Chris Hills
disi...@rootshell.be writes
>
>
>> I hope you are referring to the latest examples/code snippets released
>> (earlier this year I think) and not the snippets that came out with the
>> earlier version of the MISRA guidelines. Engineers should all be working to
>> current best practice and that means mindful of the latest and emergent
>> standards.
>>
>> I notice that the link you provided was from 2005.
>
>Correct - I have to clarify that I refer to old MISRA rules. I am not
>aware of latest MISRA rules. They are not freely available
They are freely available.
>and I have
>not access to latest rules
Chris Hills
disi...@rootshell.be writes
>> If your job requires that you write MISRA-compliant code, I would
>> think you'd learn how to avoid the warnings and stop wasting precious
>> time.
>I agree but it is annoying all the time. And the official position of
>my employer is not clean.
>And also clients of my employer think that _every_ MISRA deviation is
>dangerous and terrible.
Well you have to be able to justify them. What deviations do you want?
> And what I claim is that MISRA people are
>guilty about this situation.
What situation?
> It is not about me - I can always find
>another job. It is about many poor embedded developers all over the
>world.
They can also find other jobs.
Vladimir Vassilevsky
Chris Hills wrote:
> See http://www.phaedsys.demon.co.uk/chris/mistrayc/MISTRAYC.pdf
> for a REAL programmers guide for people who do not want their creativity
> limited.
Though it is not too creative just to take MISRA and revert every rule
upside down.
VLV
Paul E. Bennett
> They are freely available.
Unless he was another cheapskate looking for the zero cost version.
>>and I have
>>not access to latest rules
>
> http://www.misra-c.com/
...and quite reasonable prices too.
CBFalconer
> Paul E. Bennett <p...@amleth.demon.co.uk> writes
>> Chris Hills wrote:
>>
>>> You might think that I could not possibly comment
>>>
>>> See http://www.phaedsys.demon.co.uk/chris/mistrayc/MISTRAYC.pdf
>>> for a REAL programmers guide for people who do not want their
>>> creativity limited.
>
>> Except that the file could not be opened (even from the web page
>> above it).
>
> Very strange as I cut and pasted the link from the web browser....
> Can any one else see the pdf OK?
No problem here.
--
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
Jack Klein
wrote in comp.arch.embedded:
[snip]
> There will be a TC and example suite soon and a MISRA-C V3 in a few
> years. Hopefully it will have the same level of improvements between 2 &
> 3 as 1 & 2
[snip]
Chris, please be sure to post here when these things are available.
Like most people, I do not visit the MISRA web site very often
because, let's face it, it does not change very often.
Also, if you are looking for outside reviewers and/or beta users of
the TC or new version, I am willing to participate. Just email me at
my completely undisguised address.
I work, these days, in safety critical embedded control for medical
devices, and we have incorporated a large part of MISRA C in our
coding standards for several years now. I'll supply my company
affiliation via email if you want it.
Ulf Samuelsson
> expression by the following, equally unsafe code, and avoid the
> warning:
>
> u8Ptr1 = &u8Ptr2[N];
>
> Or one could even avoid pointers altogether, and write something like
> this, which can be as unsafe as the previous:
>
> N = /* complicated expression */
> a = u8Ptr2[N];
>
This can of course be made safer by a compiler if it is transformed to
N = /* complicated expression */
ASSERT(N >= &u8Ptr2[0]);
ASSERT(N < &u8Ptr2[MAX]);
a = u8Ptr2[N];
Much harder to do with a pointer
--
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
Boudewijn Dijkstra
>> If your job requires that you write MISRA-compliant code, I would
>> think you'd learn how to avoid the warnings and stop wasting precious
>> time.
> I agree but it is annoying all the time.
Anything that limits creativity is annoying. Everything that allows
creativity is limiting.
> And the official position of
> my employer is not clean.
> And also clients of my employer think that _every_ MISRA deviation is
> dangerous and terrible. And what I claim is that MISRA people are
> guilty about this situation.
MISRA would be dead today if it didn't help developers to be careful about
what they write and to solve mistakes at an early stage. Especially if
missing a deadline means endangering the jobs of hundreds of people.
Sure, it is possible to be careful and not be MISRA-compliant, but should
your boss trust _all_ his developers to be careful enough _all_ the time?
--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
Colin Paul Gloster
2007 23:14:28 +0100, "Paul E. Bennett" <p...@amleth.demon.co.uk>
posted a response to an excellent example of classic MISRA C being
awful:
"I hope you are referring to the latest examples/code snippets released
(earlier this year I think) and not the snippets that came out with the
earlier version of the MISRA guidelines. Engineers should all be working to
current best practice and that means mindful of the latest and emergent
standards.
[..]"
MISRA does not do so. From WWW.MISRA-C2.com/faqs.htm :
"[..]
Is C99 covered?
MISRA-C:2004 is based on the C language as defined by ISO 9899:1990
(plus
corrigenda). C99 has not been considered in MISRA-C:2004 due to the
limited
support for C99 on embedded microprocessors.
[..]"
Colin Paul Gloster
2007 23:09:58 +0100, "Paul E. Bennett" <p...@amleth.demon.co.uk>
posted:
"Chris Hills wrote:
> They are freely available.
Unless he was another cheapskate looking for the zero cost version.
>>and I have
>>not access to latest rules
>
> http://www.misra-c.com/
...and quite reasonable prices too."
The Ada standard is available for gratis.
Colin Paul Gloster
2007 11:03:09 -0400, John Perry <j...@no.spam> posted:
"Arlet wrote:
> ...
>
> The bigger issue is that basically *any* random C program can be
> converted into an equivalent program that complies with MISRA rules
> (or any other set of similar rules, for that matter). This conversion
> process can even be done fully automatically by a suitable tool. Of
> course, simply rewriting code into a different syntactic form does
> not, by itself, increase the safety.
>"
I had been unaware of this. How? Does this apply to all such sets of
rules?
"...and the fault with MISRA is...?
[..]"
If it does not prohibit the practices it is supposed to, then that is
a problem.
Colin Paul Gloster
2007 23:00:21 +0100, Chris Hills <ch...@phaedsys.org> posted:
"In article <1174945523.3...@n76g2000hsh.googlegroups.com>,
disi...@rootshell.be writes
[..]
>please, for those who do not code using strict misra checker: do not
>argue that MISRA is good. Without signifficant changes and
>improvements to these rules, it is not more than annoying tool.
>Compiler warnings of a good CC are far more useful to prevent bugs at
>early stage development.
And who are you to say this? You hide behind a fake email address.
Identify yourself, make the comments again ."
One does not need to identify one's self to make a comment. Do you
deny that the warning messages which were alleged are invalid? People
are unimportant. Truth is important.
Chris Hills
<Colin_Pau...@ACM.org> writes
As has been said you need to read and understand not quote the letter...
:-)
Chris Hills
<Colin_Pau...@ACM.org> writes
>In news:xRZG4jK1...@phaedsys.demon.co.uk timestamped Mon, 26 Mar
>2007 23:00:21 +0100, Chris Hills <ch...@phaedsys.org> posted:
>"In article <1174945523.3...@n76g2000hsh.googlegroups.com>,
>disi...@rootshell.be writes
>[..]
>
>>please, for those who do not code using strict misra checker: do not
>>argue that MISRA is good. Without signifficant changes and
>>improvements to these rules, it is not more than annoying tool.
>>Compiler warnings of a good CC are far more useful to prevent bugs at
>>early stage development.
>
>
>And who are you to say this?
I should have thought that was self evident.
>You hide behind a fake email address.
>Identify yourself, make the comments again ."
>
>One does not need to identify one's self to make a comment. Do you
>deny that the warning messages which were alleged are invalid? People
>are unimportant. Truth is important.
However disi...@rootshell.be made anonymous allegations against the
MISRA team. I just asked him to identify them and repeat them.
Chris Hills
Vassilevsky <antispa...@hotmail.com> writes
I just did it for fun. Also trying to invert the rules was a useful test
of the rule.
Chris Hills
<jack...@spamcop.net> writes
>On Tue, 27 Mar 2007 09:38:01 +0100, Chris Hills <ch...@phaedsys.org>
>wrote in comp.arch.embedded:
>
> [snip]
>
>> There will be a TC and example suite soon and a MISRA-C V3 in a few
>> years. Hopefully it will have the same level of improvements between 2 &
>> 3 as 1 & 2
>
> [snip]
>
>Chris, please be sure to post here when these things are available.
>Like most people, I do not visit the MISRA web site very often
>because, let's face it, it does not change very often.
Fair enough I will let you allknow when they are available.
>Also, if you are looking for outside reviewers and/or beta users of
>the TC or new version, I am willing to participate. Just email me at
>my completely undisguised address.
I use my real email address here so please send me you contact details
>I work, these days, in safety critical embedded control for medical
>devices, and we have incorporated a large part of MISRA C in our
>coding standards for several years now. I'll supply my company
>affiliation via email if you want it.
OK Yes please.
I note you use "a large part of MISRA-C" You look at MISRA-C and apply
it to your development. Not al the rules will be applicable all the
time. As long as it makes you THINK about what you are doing and avoid
some of the pitfalls of C then it has achieved it's purpose.
No one has ever said total conformance to MISRA-C at all times was going
to be possible or in deed sensible all the time. This is why some
rules are "required" and some "advisory"
Arlet
wrote:
> > The bigger issue is that basically *any* random C program can be
> > converted into an equivalent program that complies with MISRA rules
> > (or any other set of similar rules, for that matter). This conversion
> > process can even be done fully automatically by a suitable tool. Of
> > course, simply rewriting code into a different syntactic form does
> > not, by itself, increase the safety.
> >"
>
> I had been unaware of this. How? Does this apply to all such sets of
> rules?
A simple, but perverse, way to do this would be to create a virtual
machine, for example an x86 CPU emulator. The emulator would have to
be written (once) to comply with MISRA rules. You can then take a
random C program, compile it to x86 instructions, and add it as a
static array to the emulator code.
This could be done within any set of rules that still leave enough
power to construct a virtual machine, which is pretty much anything
that still classifies as a programming language.
Stefan Reuther
>>Yes, this is correct. You should not modify, alias or copy the pointers.
>>Work with arrays and indexes only.
>
> a = &x[i] is absolutely equivalent to a=x+i (assuming i is an integer
> and a&x are pointers of the same type).
No, it's not. While '&x[i]' requires the element i to exist (i.e. array
x must have at least i+1 elements), 'x+i' doesn't. If your compiler can
do array bounds checks, it will probably do that for '&x[i]', but not
for 'x+i'.
Stefan
John Perry
> In news:9maOh.94188$ia7....@newsfe14.lga timestamped Tue, 27 Mar
> 2007 11:03:09 -0400, John Perry <j...@no.spam> posted:
>
> "...and the fault with MISRA is...?
>
> [..]"
>
> If it does not prohibit the practices it is supposed to, then that is
> a problem.
The answer, of course, was in the paragraph above, which you deleted:
"MISRA and such are not intended to be proof against the bad guys..."
John Perry
Richard Pennington
Hmm. &x[i] does not require that x has i+1 elements. In fact it is
explicitly mentioned in the standard when x has exactly i elements.
I don't think the standard has changed the fact that for a pointer (or
array name) x and an integer i that
x + i == i + x == &x[i] == &i[x]
Has it?
-Rich
Hans-Bernhard Bröker
> disi...@rootshell.be wrote:
>> a = &x[i] is absolutely equivalent to a=x+i (assuming i is an integer
>> and a&x are pointers of the same type).
> No, it's not. While '&x[i]' requires the element i to exist (i.e. array
> x must have at least i+1 elements), 'x+i' doesn't.
You're quite completely wrong there. &x[i] is required by the standard
to be exactly the same as x+i, because:
1) x[i] is required to be completely equivalent to *(x+i). The []
operator is actually defined by this very property.
2) &*(pointer) is required to be equivalent to (pointer), expressly
including that such an expression does not comprise a dereference of the
pointer, i.e. it doesn't trigger any additonal requirements on the value
of (pointer).
David Brown
The C standard says that "x + i" and "&x[i]" have the same value.
However, &x[i] is only valid if x has at least i elements (not
necessarily (i + 1) - the address beyond the top of the array is also
valid). The compiler should generate the expected code for &x[i] with
out of range i, but it is not guaranteed.
However, any good C compiler, or other C analyser like lint, will
interpret "&x[i]" and "x + i" differently, as they operate on a higher
level than blind code generation. On an array access, they can do a
certain amount of static range checking - some C compilers may even have
the option for run-time range checking. The compiler may also be able
to do better alias analysis and therefore generate better code with the
array access (since it knows the range the resultant pointer could take).
All this is, of course, subservient to the golden rule of writing
understandable code. If "i" is an index into the array "x", then the
correct form is "&x[i]" - "x + i" does not say what you mean, and is
therefore bad code.
> -Rich
Richard Pennington
[snip]
> The C standard says that "x + i" and "&x[i]" have the same value.
> However, &x[i] is only valid if x has at least i elements (not
> necessarily (i + 1) - the address beyond the top of the array is also
> valid). The compiler should generate the expected code for &x[i] with
> out of range i, but it is not guaranteed.
>
> However, any good C compiler, or other C analyser like lint, will
> interpret "&x[i]" and "x + i" differently, as they operate on a higher
> level than blind code generation. On an array access, they can do a
> certain amount of static range checking - some C compilers may even have
> the option for run-time range checking. The compiler may also be able
> to do better alias analysis and therefore generate better code with the
> array access (since it knows the range the resultant pointer could take).
Not really. "Any good C compiler" could recognize "x + i" as identical
to "&x[i]". In fact, whether or not pointers are involved with data flow
analysis, range checking could also be done.
>
> All this is, of course, subservient to the golden rule of writing
> understandable code. If "i" is an index into the array "x", then the
> correct form is "&x[i]" - "x + i" does not say what you mean, and is
> therefore bad code.
My favorite is 3["Hello world"] == 'l'.
Well, maybe not my favorite, but one of my top 10. ;-)
-Rich
Dave Hansen
[...]
>
> My favorite is 3["Hello world"] == 'l'.
>
> Well, maybe not my favorite, but one of my top 10. ;-)
My favorite, which is actually in use in code somewhere, is similar to
digit = "0123456789ABCDEF"[value & 0x0F];
Regards,
-=Dave
CBFalconer
>
... snip ...
>
> My favorite is 3["Hello world"] == 'l'.
#define true ('r' == 5["foobar"])
#define false !true
CBFalconer
> Richard Pennington <r...@pennware.com> wrote:
> [...]
>>
>> My favorite is 3["Hello world"] == 'l'.
>>
>> Well, maybe not my favorite, but one of my top 10. ;-)
>
> 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.
Stefan Reuther
> Stefan Reuther wrote:
>> disi...@rootshell.be wrote:
>>> a = &x[i] is absolutely equivalent to a=x+i (assuming i is an integer
>>> and a&x are pointers of the same type).
>
>> No, it's not. While '&x[i]' requires the element i to exist (i.e. array
>> x must have at least i+1 elements), 'x+i' doesn't.
>
> You're quite completely wrong there. &x[i] is required by the standard
> to be exactly the same as x+i, because:
>
> 1) x[i] is required to be completely equivalent to *(x+i). The []
> operator is actually defined by this very property.
Indeed. C99 says "The unary & operator returns the address of its operand.
[...] If the operand is the result of a [] operator, neither the & operator
nor the unary * that is implied by the [] is evaluated and the result is as
if the & operator were removed and the [] operator were changed to a +
operator."
However, if I see that correctly, neither C90 nor C++98 make that exception,
making "*(x+i)" a constraint violation if x has only i elements, even if the
"&" operator is applied to it afterwards.
That aside, I would assume that a normal (=not bounds-checking) compiler
generates the same machine code for &x[i] and x+i anyway.
Stefan
Tom Lucas
news:W+j$TdDdxp...@phaedsys.demon.co.uk...
> In article <2xgOh.9590$JZ3....@newssvr13.news.prodigy.net>, Vladimir
> Vassilevsky <antispa...@hotmail.com> writes
>>
>>
>>Chris Hills wrote:
>>
>>
>>> See http://www.phaedsys.demon.co.uk/chris/mistrayc/MISTRAYC.pdf
>>> for a REAL programmers guide for people who do not want their
>>> creativity limited.
>>
>>Though it is not too creative just to take MISRA and revert every rule
>>upside down.
>>
>>VLV
>
> I just did it for fun.
Perhaps I might I suggest fishing, golf, stamp collecting...
;-)
Tom Lucas
news:460B0955...@yahoo.com...
> Dave Hansen wrote:
>> Richard Pennington <r...@pennware.com> wrote:
>> [...]
>>>
>>> My favorite is 3["Hello world"] == 'l'.
>>>
>>> Well, maybe not my favorite, but one of my top 10. ;-)
>>
>> 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.
Vladimir Vassilevsky
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.
If this would be just:
variable = variable + 1;
There would be no bug.
//---------------------------------------
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
msg
>
> 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.
>
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).
Regards,
Michael
Everett M. Greene
> Yes, this is correct. First of all, an integer should not
> be used as the switch argument; switches should be used
> with enums only.
I believe you are mistaken about not allowing integers
to be used as a switch argument. The C standard says
the switch argument is required to be an integer
expression. Perhaps you meant to say that integers
shouldn't be used as the case identifiers.
However, I quite often have situations where a portion
of a value is extracted and used as an index for a switch
statement. I should define:
enum integer {zero, one, two, three,...}
switch(index) {
case zero:
break;
...
}
etc.?
I also regularly write switch statements that are using
a character as the switch index/argument. I should
define:
enum alpha {a, b, c, d, e,...}?
ChrisQuayle
> 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...
Chris
CBFalconer
>>
... 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".
Chris Hills
<nos...@devnul.co.uk> writes
Hopefully by the end of the year.
ChrisQuayle
> In article <pKROh.17989$NK3....@newsfe6-win.ntli.net>, ChrisQuayle
> <nos...@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
CBFalconer
> 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.
msg
> 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
CBFalconer
>
... 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.
Ulf Samuelsson
> 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
msg
> 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
Chris Hills
<nos...@devnul.co.uk> writes
>Chris Hills wrote:
>> In article <pKROh.17989$NK3....@newsfe6-win.ntli.net>, ChrisQuayle
>><nos...@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.
Tom Lucas
> Tom Lucas wrote:
>> "CBFalconer" <cbfal...@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.
Arlet
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).
Boudewijn Dijkstra
<antispa...@hotmail.com>:
> u8 variable;
> variable = (u8)(variable + 1);
>
> variable = (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/
Vladimir Vassilevsky
I top post to make you a pleasure.
FYI: It doesn't make any difference if you do x = x+1 or x++.
By C convention, it is treated as x = (int)x + (int)1 in the either
variant. Therefore:
u8 x; x++;
will produce the same MISRA warning about downcasting as x = x + 1;
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
Dave Hansen
> 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.
Or at a minimum, the cast should be in the other direction:
if ( (size_t)space < strlen(message) + 1 )
It seems to me that it is less likely that "space" is negative than it
would be that "strlen(message)+1" would overflow an int. And even if
space _is_ negative, the code is very likely broken in ways worse than
an unnecessary cast...
Regards,
-=Dave
Robert Adsett
> Op Thu, 29 Mar 2007 16:48:48 +0200 schreef Vladimir Vassilevsky
> <antispa...@hotmail.com>:
> > u8 variable;
> > variable = (u8)(variable + 1);
> >
> > u16 variable;
> > variable = (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.
OK, I give up. How does typeof help here?
Robert
Robert Adsett
I thought I'd try PC-Lint on some of these and see what popped out.
Some overhead left out but here is what I ran along with the resulting
messages and some of my own commentary.
size_t strlen (const char *s);
void test(const char *mess)
{
extern unsigned char variable1;
extern unsigned int variable2;
extern int space;
extern size_t space2;
variable1 = variable1 + 1;
variable1 = (unsigned char)(variable1 + 1);
variable2 = (unsigned char)(variable2 + 1);
variable1++;
variable2++;
+++ No messages for any of the above. I know PC-Lint checks for a
subset of the MISRA messages but I'm guessing only for the previous
version. It's been a little while since I read the previous version but
I don't remember a rule that would require a cast in these cases and
that sort of check is certainly within PC-Lint's capability. As far as
there being no complaints when the cast is added I think that falls
under "If you lie to the compiler it will get its revenge."
if ( space < strlen(mess) + 1 ) {
}
/*
test2.c 55 Note 961: Violates MISRA
Advisory Rule 47, dependence placed on C's operator precedence;
operators:
'<' and '+'
test2.c 55 Warning 639: Strong type
mismatch for type 'size_t' in binary operation
test2.c 55 Warning 574: Signed-unsigned mix
with relational
test2.c 55 Info 737: Loss of sign in
promotion from int to unsigned long
*/
if ( space < (strlen(mess) + 1) ) {
}
/*
test2.c 71 Warning 639: Strong type
mismatch for type 'size_t' in binary operation
test2.c 71 Warning 574: Signed-unsigned mix
with relational
test2.c 71 Info 737: Loss of sign in
promotion from int to unsigned long
*/
if ( space < (int)strlen(mess) + 1 ) {
}
/*
e:\cygwin\home\radsett\newlib-lpc\test2.c 84 Note 961: Violates MISRA
Advisory Rule 47, dependence placed on C's operator precedence;
operators:
'<' and '+'
*/
if ( space2 < strlen(mess) + 1 ) {
}
/*
e:\cygwin\home\radsett\newlib-lpc\test2.c 92 Note 961: Violates MISRA
Advisory Rule 47, dependence placed on C's operator precedence;
operators:
'<' and '+'
e:\cygwin\home\radsett\newlib-lpc\test2.c 92 Warning 639: Strong type
mismatch for type 'size_t' in binary operation
e:\cygwin\home\radsett\newlib-lpc\test2.c 92 Warning 638: Strong type
mismatch for type 'size_t' in relational
*/
if ( space2 < (strlen(mess) + (size_t)1) ) {
}
+++ This last one is the most interesting as far as I'm concerned.
Although having the value compared to string length being a size_t is
'the correct thing to do' as far as I'm concerned, having space2 as a
size_t is not sufficient. All the little constants involved need to be
size_t as well. Ugly.
}
Robert
CBFalconer
> Boudewijn Dijkstra says...
>> schreef Vladimir Vassilevsky <antispa...@hotmail.com>:
>>
>>> u8 variable;
>>> variable = (u8)(variable + 1);
>>>
>>> u16 variable;
>>> variable = (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.
>
> OK, I give up. How does typeof help here?
It doesn't. The proper action is to remove the cast and let the
compiler perform the default conversions. It helps to understand
warnings and what they are worrying about. Then you make an
intelligent decision about ignoring them, and maybe even leave a
comment for the poor maintainer.
typeof is not generally available, and is definitely not standard.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Ulf Samuelsson
news:460DC48E...@yahoo.com...
> Robert Adsett wrote:
>> Boudewijn Dijkstra says...
>>> schreef Vladimir Vassilevsky <antispa...@hotmail.com>:
>>>
>>>> u8 variable;
>>>> variable = (u8)(variable + 1);
>>>>
>>>> u16 variable;
>>>> variable = (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.
>>
>> OK, I give up. How does typeof help here?
>
> It doesn't. The proper action is to remove the cast and let the
> compiler perform the default conversions. It helps to understand
> warnings and what they are worrying about. Then you make an
> intelligent decision about ignoring them, and maybe even leave a
> comment for the poor maintainer.
>
> typeof is not generally available, and is definitely not standard.
>
> --
Maybe we need a new C keyword for such type conversions.
variable = (sortof)(variable + 1); // Convert, if it is the right
thing to do :-)
Chris Hills
<su...@aeolusdevelopment.com> writes
>
>+++ No messages for any of the above. I know PC-Lint checks for a
>subset of the MISRA messages but I'm guessing only for the previous
>version.
There are MISRA-C files for both versions on their web site.
Hans-Bernhard Bröker
> 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)
If *that* line is actually in the source (as you say), that disqualifies
the entire example. Both uint_t and size_t are typedefs provided by
standard headers. Definining either of them yourself would be folly
already. But defining the older one (size_t) by reference to the newer
(uint_t) is outright crazy.
In a nutshell: typedef'ing size_t yourself is suicide for any program
that tries to be portable.
> void store_error_message ( char *message );
> int space;
> ...
> if ( space < strlen(message) + 1 ) {
>
> No warnings under GCC.
That only demonstrates you don't know how to ask GCC for warnings. In
particular, you failed to enable -Wsign-compare.
> The line should have been written:
>
> if ( space < (int)strlen(message) + 1 ) {
Not based on the evidence you presented it shouldn't. It should rather
be redesigned from the ground up, by answering the following questions:
1) why is "space" typed int instead of size_t?
2) what is supposed to happen if "space" turns negative?
3) what is supposed to happen if (strlen(message) > INT_MAX)?
4) what is supposed to happen if (strlen == SIZE_MAX)?
Hans-Bernhard Bröker
> FYI: It doesn't make any difference if you do x = x+1 or x++.
>
> By C convention, it is treated as x = (int)x + (int)1 in the either
> variant.
Bzzzt, you're out. Thanks for playing.
You're wrong on two counts here.
1) No, x++ is not equivalent to adding a literal 1 (which would indeed
have type int). It's defined to add "the value 1 of the appropriate
type" (C99 6.5.2.4p2). I.e. for the case of an 8-bit variable x, it's
equivalent to
x += (u8) 1;
The cast that MISRA rules insist on would be implied in using the ++
operator.
2) Your u16 type is presumably equivalent to C99's uint16_t, right?
Then the above would be correct only on platforms where int is larger
than 16 bits. On 16-bit platforms, ++ applied to a uint16_t variable x
is actually equivalent to
x = x + (unsigned int)1;
msg
> msg wrote:
>
>> 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)
>
>
> If *that* line is actually in the source (as you say), that disqualifies
> the entire example.
Sorry, no, it is an excerpt from the standard headers (to put the rest
of the example into context).
> Both uint_t and size_t are typedefs provided by
> standard headers. Definining either of them yourself would be folly
> already. But defining the older one (size_t) by reference to the newer
> (uint_t) is outright crazy.
> In a nutshell: typedef'ing size_t yourself is suicide for any program
> that tries to be portable.
Did not happen.
>
>> void store_error_message ( char *message );
>> int space;
>> ...
>> if ( space < strlen(message) + 1 ) {
>>
>> No warnings under GCC.
>
>
> That only demonstrates you don't know how to ask GCC for warnings. In
> particular, you failed to enable -Wsign-compare.
Thanks for pointing out that switch. As I said, these are packages from
authors who don't properly consider the implications of precedence of operators
and typing (and that includes a lot of well-known code). In general I clean
up the code to at least build without warnings on my SVR4 target and
submit patches which are usually ignored. I don't make the _impossible_\
to_debug autoconf scripts which are usually the culprit in setting compiler
warning switches.
>
>> The line should have been written:
>>
>> if ( space < (int)strlen(message) + 1 ) {
>
>
> Not based on the evidence you presented it shouldn't. It should rather
> be redesigned from the ground up, by answering the following questions:
>
> 1) why is "space" typed int instead of size_t?
(it is used in calls to other library functions that expect type int)
> 2) what is supposed to happen if "space" turns negative?
(admittedly not handled in the code but only possible by a catastrophe)
> 3) what is supposed to happen if (strlen(message) > INT_MAX)?
(only possible by catastrophe)
> 4) what is supposed to happen if (strlen == SIZE_MAX)?
(only possible by catastrophe)
Agreed that the code should address all of the above; suggestions along
those lines are usually met with silence by the authors.
My point is that even with the deficiencies in the design of
code at least the authors should clearly manage typing which also
avoids vast amounts of error diagnostics from my target's compiler.
Regards,
Michael
msg
> In article <130p2dp...@corp.supernews.com>, msg says...
>
>>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:
<snip>
>
> I thought I'd try PC-Lint on some of these and see what popped out.
> Some overhead left out but here is what I ran along with the resulting
> messages and some of my own commentary.
<snip>
Thanks for the tests and results.
Regards,
Michael
msg
> msg wrote:
>
>> I should have provided an example. Here is a line from a popular
>> opensource X10 automation package developed by its author on linux/gcc:
(excerpt from system header):
>> typedef uint_t size_t; (unsigned int on both SVR4 and linux)
>
> In a nutshell: typedef'ing size_t yourself is suicide for any program
> that tries to be portable.
>
As to portability, very few authors of linux-targeted software (which
for the most part is claimed to be portable) ever consider an int size
< 32 bits unfortunately and never ever consider that their code would
be ported beyond their parochial world.
Regards,
Michael
Hans-Bernhard Bröker
> Hans-Bernhard Bröker wrote:
>> That only demonstrates you don't know how to ask GCC for warnings. In
>> particular, you failed to enable -Wsign-compare.
> Thanks for pointing out that switch. As I said, these are packages from
> authors who don't properly consider the implications of precedence of
> operators and typing (and that includes a lot of well-known code). In general I
> clean up the code to at least build without warnings on my SVR4 target and
> submit patches which are usually ignored.
Not meaning any disrespect: if the patches you submit are of the same
type as this one:
>>> The line should have been written:
>>>
>>> if ( space < (int)strlen(message) + 1 ) {
I find it hard to blame the recipients for not taking them at face
value. There are at least three ways this line might best have been
written. You discard all but one for no good reason to be seen.
> I don't make the _impossible_to_debug_ autoconf scripts which are
> usually the culprit in setting compiler warning switches.
They're not. The autoconf machinery is for _creating_ the makefile, and
as part of that job, it has to set up a generally usable default set of
compiler switches. But that's in no way limiting your flexibility in
using them. 'make CFLAGS="-g -O2 -Wall -W"' works just fine.
>> Not based on the evidence you presented it shouldn't. It should
>> rather be redesigned from the ground up, by answering the following
>> questions:
>> 1) why is "space" typed int instead of size_t?
> (it is used in calls to other library functions that expect type int)
But should this same "space" be used _here_? Or is it maybe those
library functions' design that really is at fault here, for having
arguments of class "size of something" with a signed type?
>> 2) what is supposed to happen if "space" turns negative?
> (admittedly not handled in the code but only possible by a catastrophe)
>> 3) what is supposed to happen if (strlen(message) > INT_MAX)?
> (only possible by catastrophe)
>> 4) what is supposed to happen if (strlen == SIZE_MAX)?
> (only possible by catastrophe)
So you've just judged all those case in which it would make any
difference at all whether you put this cast as "catastrophic" ones,
which apparently you're not going to bother with. Why then would you be
bothered about getting the cast right?
If "space" really can't be negative, the original comparison without the
cast is perfectly OK. You'll have to make up your mind: either you're
worried about extreme, "catastrophic" cases, or you're not.
msg
> msg wrote:
>
>> Hans-Bernhard Bröker wrote:
>
>
>>> That only demonstrates you don't know how to ask GCC for warnings.
>>> In particular, you failed to enable -Wsign-compare.
>
>
>> Thanks for pointing out that switch. As I said, these are packages from
>> authors who don't properly consider the implications of precedence of
>> operators and typing (and that includes a lot of well-known code). In
>> general I clean up the code to at least build without warnings on my
>> SVR4 target and submit patches which are usually ignored.
I should also have mentioned 'and also pass functional and regression
tests on my target'.
>
>
> Not meaning any disrespect: if the patches you submit are of the same
> type as this one:
>
>>>> The line should have been written:
>>>>
>>>> if ( space < (int)strlen(message) + 1 ) {
>
> I find it hard to blame the recipients for not taking them at face
> value. There are at least three ways this line might best have been
> written. You discard all but one for no good reason to be seen.
>
Actually, this particular one came _from_ the author, not me;
I merely provided the diagnostics to him. My references to patches
was not related to this issue necessarily and when it is
I _do_ take care to analyze the logic and rework where necessary,
not just typecast to avoid warnings ;)
The point of my original post was that this issue is hardly considered
by authors of many well-known programs developed using GCC, with warning
levels in common use, and those authors are usually disinterested in
rectifying what they feel is not broken.
Regards,
Michael
Colin Paul Gloster
Mar 2007 16:23:49 GMT, ChrisQuayle <nos...@devnul.co.uk> posted:
"Colin Paul Gloster wrote:
> The Ada standard is available for gratis.
The point being ?."
The Ada standard with unsuitable aspects prohibited (such as by using
pragma Profile (RAVENSCAR);
(
WWW.AdaIC.org/standards/05rm/html/RM-D-13-1.html
)) is better than the MISRA standard. (Disclaimer: I claim this
without actually having read the MISRA standard.) One can check that
the Ada standard is good for free.
" Would you expect to get a usefull book for nothing
that someone has spent considerable time and effort to produce,"
Yes: the Ada 2005 standard is available for gratis. I had already
stated that and you quoted that.
" or
should everything be open source and free ?."
Arguably not everything.
" Of course, including all
your own work."
I am paid entirely by taxes as a researcher, so of course all of my
current work should be available for no extra charge and subject to peer review
and criticism. My tutors do not agree. Other work I had done was for a
private former employer which has the right to choose whether or not that work
is open source and whether or not that work is free to others. One
thing such a former employer can not do is choose for that work to be
free to the former employer because I had already been paid.
"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."
So perhaps I have misjudged MISRA standards from rumors.
As you like paying for things so much, may I charge you for reading
this post?
"The C++ version should be quite interesting..."
Should a sane embedded engineer use C++?
Chris Hills
<Colin_Pau...@ACM.org> writes
>" Would you expect to get a usefull book for nothing
>that someone has spent considerable time and effort to produce,"
>
>Yes: the Ada 2005 standard is available for gratis. I had already
> stated that and you quoted that.
Ada was NOT FREE It cost the US government several million pounds. The
only reason it was "Free" is because the US government wanted everyone
to use this language on US military projects.
It costs a lot of money to make a standard like MISRA-C are you going to
fund it?
>" Of course, including all
>your own work."
>
>I am paid entirely by taxes as a researcher,
That explains a hell of a lot :-)
> so of course all of my
>current work should be available for no extra charge and subject to peer review
>and criticism. My tutors do not agree.
Available to who for free?
>So perhaps I have misjudged MISRA standards from rumors.
SO you are arguing about something you have not yet seen?
>"The C++ version should be quite interesting..."
>
>Should a sane embedded engineer use C++?
Is this a philosophical, social, engineering or commercial question?
Ask yourself why MISRA is doing a C++ standard
For some years I said "over our dead bodies" Yet one is being done.
Unfortunately I can only ask the question. I can't supply the answer.
Vladimir Vassilevsky
Chris Hills wrote:
> In article <eun74d$vpv$1...@newsserver.cilea.it>, Colin Paul Gloster
> <Colin_Pau...@ACM.org> writes
>
>> Yes: the Ada 2005 standard is available for gratis. I had already
>> stated that and you quoted that.
It happens somehow that the free cheese exists only in the mouse traps.
>
> Ada was NOT FREE It cost the US government several million pounds. The
> only reason it was "Free" is because the US government wanted everyone
> to use this language on US military projects.
I don't mind using Ada, but where are the compilers? This looks like
another perfectly designed still born thing.
>> Should a sane embedded engineer use C++?
> Is this a philosophical, social, engineering or commercial question?
It is not a question. The sane embedded engineer must use C++.
VLV
Vladimir Vassilevsky
Chris Hills wrote:
> Ask yourself why MISRA is doing a C++ standard
> For some years I said "over our dead bodies" Yet one is being done.
By design, C is the assembler of higher level. And C++ is the macro
assembler. Then what is going to be used as the main application
development language after C++ ? I guess that would be an interpeter
like LabView.
Chris Hills
Vassilevsky <antispa...@hotmail.com> writes
>Chris Hills wrote:
>> In article <eun74d$vpv$1...@newsserver.cilea.it>, Colin Paul Gloster
>><Colin_Pau...@ACM.org> writes
>>> Yes: the Ada 2005 standard is available for gratis. I had already
>>> stated that and you quoted that.
>It happens somehow that the free cheese exists only in the mouse traps.
Those in industry, or in fact anywhere outside a sheltered environment
will know there is no such thing as a free lunch.
>> Ada was NOT FREE It cost the US government several million pounds.
>>The only reason it was "Free" is because the US government wanted
>>everyone to use this language on US military projects.
>
>I don't mind using Ada, but where are the compilers? This looks like
>another perfectly designed still born thing.
This is the other point there are many languages "better" than C but
without wide spread tool support they will not gain wide spread use. So
these languages are not universally available for many hosts or targets.
>>> Should a sane embedded engineer use C++?
>> Is this a philosophical, social, engineering or commercial question?
>
>It is not a question. The sane embedded engineer must use C++.
Please expand... this is not a troll but I am interested in your
reasoning though I am assuming you are not suggesting C++ for PIC's and
8051's etc
Simon Clubley
>
> I don't mind using Ada, but where are the compilers? This looks like
> another perfectly designed still born thing.
>
Ada is available as part of GCC.
You can either use a FSF distribution of GCC, which has no restrictions
on what you can use the Ada compiler for, or you can use a packaged
distribution from ACT, which is restricted to GPL only projects.
See https://libre.adacore.com/ for the packaged version. Note that I've no
experience with this distribution because I prefer to use the FSF
distributions so that I'm not restricted in what I can use the compiler for.
Note also that the RTEMS RTOS has support for using Ada, but the support
level appears to vary by architecture.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world
Vladimir Vassilevsky
Chris Hills wrote:
>>>> Should a sane embedded engineer use C++?
>>> Is this a philosophical, social, engineering or commercial question?
>> It is not a question. The sane embedded engineer must use C++.
>
> Please expand... this is not a troll but I am interested in your
> reasoning though I am assuming you are not suggesting C++ for PIC's and
> 8051's etc
1. The performance of the today's low end 8-bitter is comparable to that
of the desktop computer about 15 years ago. The speed and size are
rarely the issue; geting the project done on time and for good is more
important.
2. The marketing requirements are growing at every year. Although the
substantial part of, say, PID regulator is not too different from what
it was 50 years before, now they want a lot of bells and whistles
around. The development of interfaces and other non essential things
takes the majority of the effort.
3. Therefore any project consists of a conceptual part, which should be
done right, and a big pile of rather trivial legwork. The backbone of
the application has to be set by a master, whereas the routine can be
left to the apprentices. Masters are rare and expensive; apprentices are
likely to screw up. The C++ helps avoiding many dumb mistakes of the
apprentice level.
4. Aside from the development of features, there is another big part:
handling of errors and miscellaneous special cases. The C++ philosophy
helps here too (This is not only about the exceptions).
5. So far C++ seems to be the best compromise between the convenience
and the efficiency. The particularly good property of C++ is that if you
don't like a feature, you don't have to use it.
Chris Hills
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes
>In article <KFPPh.4279$YL5....@newssvr29.news.prodigy.net>, Vladimir
>Vassilevsky <antispa...@hotmail.com> writes:
>>
>> I don't mind using Ada, but where are the compilers? This looks like
>> another perfectly designed still born thing.
>>
>
>Ada is available as part of GCC.
>
>You can either use a FSF distribution of GCC, which has no restrictions
>on what you can use the Ada compiler for, or you can use a packaged
>distribution from ACT, which is restricted to GPL only projects.
>
>See https://libre.adacore.com/ for the packaged version. Note that I've no
>experience with this distribution because I prefer to use the FSF
>distributions so that I'm not restricted in what I can use the compiler for.
>
>Note also that the RTEMS RTOS has support for using Ada, but the support
>level appears to vary by architecture.
And this is suitable for safety critical projects?
Simon Clubley
>
> And this is suitable for safety critical projects?
>
I'm not going to make any judgement on that because I don't have any safety
critical experience. You would have to, for example, talk to ACT about what
they recommend in that situation.
I was just addressing Vladimir's comments that no Ada compilers appeared
to exist.
Jonathan Kirwan
wrote:
><snip>
>Those in industry, or in fact anywhere outside a sheltered environment
>will know there is no such thing as a free lunch.
><snip>
To a meaningful degree, there is. To name just one -- the atmosphere
-- where various gases are dumped without taking into fair account
their attendant costs. Basically any uncontrolled commons resource
represents a free lunch in the sense that folks today can nearly
completely discount the much greater costs some substantial time
later. That looks 'free lunch' to me, if not entirely moral.
Jon
ChrisQuayle
>
> The point being ?."
>
> The Ada standard with unsuitable aspects prohibited (such as by using
> pragma Profile (RAVENSCAR);
How can you make any comparison if you have no knowledge of the
standard. To put this into perspective, it costs only approx 10.00 uk
pounds, less that you would pay for a round of beers. Isn't such an
effort worth something in terms of professional development ?.
In any case, your logic is flawed. It doesn't follow that because one
object in a class of objects is available at no cost, all the rest of
the objects in that class should be free, which in effect is what you
are arguing.
> I am paid entirely by taxes as a researcher, so of course all of my
> current work should be available for no extra charge and subject to peer review
> and criticism. My tutors do not agree. Other work I had done was for a
> private former employer which has the right to choose whether or not that work
> is open source and whether or not that work is free to others. One
> thing such a former employer can not do is choose for that work to be
> free to the former employer because I had already been paid.
>
If you are a researcher, perhaps you would care to comment further on
the outrageous charges for online research reports these days, both
current and historical. Much of the work originally funded by the
taxpayer, but being openly sold at prices that make them inaccessable to
all but well heeled individuals or large organisations. $25 to $50 per
report, or several thousand dollars per annum is not unusual, for stuff
that has already been paid for. The results of publicly finded research
should be available at cost to anyone who wishes to access it, but
that's far from the case now. The Nasa tech reports server is a shining
exception, however and there are other organisations with altruistic
rather than a greedy, grasping attitude.
>
>
> As you like paying for things so much, may I charge you for reading
> this post?
>
No, because one would assume that you have already accepted the culture
of usenet, where anything posted is expected to be read by a worldwide
audience.
>
>
> "The C++ version should be quite interesting..."
>
> Should a sane embedded engineer use C++?
Open to debate I guess. C++ may have a role for consumer electronics
applications, where recovery is usually power off and reboot, but is it
really ready or appropriate for mission critical work ?...
Chris
Vladimir Vassilevsky
ChrisQuayle wrote:
> Open to debate I guess. C++ may have a role for consumer electronics
> applications, where recovery is usually power off and reboot, but is it
> really ready or appropriate for mission critical work ?...
A fear of savages before a steam locomotive?
VLV
Chris Hills
<nos...@devnul.co.uk> writes
>> "The C++ version should be quite interesting..."
>> Should a sane embedded engineer use C++?
>
>Open to debate I guess. C++ may have a role for consumer electronics
>applications, where recovery is usually power off and reboot, but is it
>really ready or appropriate for mission critical work ?...
The US Joint Strike Fighter uses C++ not Ada
Incidentally JSF++ is based on MISRA-C:1998
Robert Adsett
> In article <MPG.207797f86...@free.teranews.com>, Robert Adsett
> <su...@aeolusdevelopment.com> writes
> >In article <130p2dp...@corp.supernews.com>, msg says...
> >I thought I'd try PC-Lint on some of these and see what popped out.
>
> >
> >+++ No messages for any of the above. I know PC-Lint checks for a
> >subset of the MISRA messages but I'm guessing only for the previous
> >version.
>
> There are MISRA-C files for both versions on their web site.
Thought I'd check them out to see if they enabled anything I hadn't
already. It looks like there have been a few changes introduced that
slipped by me. There is only a significant effect on the first test
cases so I'll just repost those
void test(const char *mess)
{
extern unsigned char variable1;
extern unsigned int variable2;
extern int space;
extern size_t space2;
variable1 = variable1 + 1;
/*
test2.c 44 Note 960: Violates MISRA 2004
Required Rule 10.1, Prohibited Implicit Conversion: Signed versus
Unsigned
*/
variable1 = (unsigned char)(variable1 + 1);
/*
test2.c 46 Note 960: Violates MISRA 2004
Required Rule 10.1, Prohibited Implicit Conversion: Signed versus
Unsigned
*/
variable2 = (unsigned char)(variable2 + 1);
/*
test2.c 48 Note 960: Violates MISRA 2004
Required Rule 10.1, Prohibited Implicit Conversion: Signed versus
Unsigned
test2.c 48 Note 960: Violates MISRA 2004
Required Rule 10.1, Prohibited Implicit Conversion: Converting
complex
expression
*/
variable1++;
variable2++;
Note: this is after turning off the check for rule 6.3 which essentially
prohibits dirrct use of C's native types. It produces way too much
noise in this example.
Colin Paul Gloster
2007 14:04:23 +0100, Chris Hills <ch...@phaedsys.org> posted:
"In article <eun74d$vpv$1...@newsserver.cilea.it>, Colin Paul Gloster
<Colin_Pau...@ACM.org> writes
>" Would you expect to get a usefull book for nothing
>that someone has spent considerable time and effort to produce,"
>
>Yes: the Ada 2005 standard is available for gratis. I had already
> stated that and you quoted that.
Ada was NOT FREE It cost the US government several million pounds. The
only reason it was "Free" is because the US government wanted everyone
to use this language on US military projects."
The Ada standard did not cost me several million dollars. I never said
that the Ada standard did not "cost the US government several million"
dollars. It "is available for gratis" to someone who is not the US
government, as I had said.
"It costs a lot of money to make a standard like MISRA-C are you going to
fund it?"
No. I have no need of MISRA-C.
"[..]
>
>I am paid entirely by taxes as a researcher,
That explains a hell of a lot :-) "
:)
"> so of course all of my
>current work should be available for no extra charge and subject to peer revie
w
>and criticism. My tutors do not agree.
Available to who for free?"
Available to tax payers in an imaginary universe in which academia is
accountable to tax payers and in which refereed journals actually
conducted science by checking claims in submissions instead of taking
them on faith.
">So perhaps I have misjudged MISRA standards from rumors.
SO you are arguing about something you have not yet seen?
[..]"
Yes. If you want, I can provide you with legal copies of the Ada standard
and the two most recent Ada ex-standards at no expense to you if you
provide me with a legal copy of the MISRA C standard and a legal copy
of the MISRA C ex-standard, both at no cost to me.