msg wrote:
> 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.  <snip>

I'm building 'dcc', the x86 decompiler from Queensland, on SVR4 at the
moment; interesting that the source code is written for Borland C on
MS-DOS and yet in the 'perfect hash function' module, I found this:

/*
  *$Log: perfhlib.c,v $
  * Revision 1.5  93/09/29  14:45:02  emmerik
  * Oops, didn't do the casts last check in
  *
  * Revision 1.4  93/09/29  14:41:45  emmerik
  * Added casts to mod instructions to keep the SVR4 compiler happy
...

Regards,

Michael

In an email to the Team-Ada email list (whose archives are
unfortunately not available without a password any more) timestamped
Mon, 21 Jun 1999 10:21:46 -0500, W. Wesley Groleau wrote:

"[..]

I read the first two-thirds of the so-called classic "C Traps and
Pitfalls" There was a nearly incomprehensible two pages about the
subtle
differences between various long strings of parentheses and asterisks.
The rest of it, I thought I understood well enough to know that the
errors
just plain can't occur in Ada.  I've read more than one item advising
that
code should be carefully reviewed by salaried humans for certain types
of
errors _before_ compiling--types of errors that an Ada compiler will
find
in the time a human takes to study ten SLOC of code.

[..]"

I do not know which of the 29 page pitfalls paper and the book upon
which it was based W. Wesley Groleau referred to, and I confess I used
to not remember this email very well (I thought he wrote about Les
Hatton's "Safer C" before I checked) but nothing from an apologist for
MISRA C in this thread so far has been even a hint that MISRA C is
even at least as good as Ada.



From
WWW.LesHatton.org/Documents/MISRA_comp_1105.pdf
:"Language subsetting in an industrial context: a
comparison of MISRA C 1998 and MISRA C
2004
Les Hatton
CISM, University of Kingston*
November 20, 2005
Abstract
The MISRA C standard [7] first appeared in 1998 with the objective
of providing a set of guidelines to restrict features in the ISO C
language
of known undefined or otherwise dangerous behaviour. The standard was
assembled by representatives of a number of companies in the
automobile
sector in response to the rapidly growing use of C in electronic
embedded
systems in automobiles. The standard attempts to build on the earlier
work of [6], [3] and others. Due to various perceived deficiencies,
notably
considerable ambiguity in the rule definitions, a revision was planned
and
eventually appeared in 2004. This paper measures how well the two
standards
compare on the same population of software and also determines
how well the 2004 version achieved its stated goals. Given its
increasing
influence, the results raise important concerns.

[..]

[..] Regrettably, successful compilation is usually not a
quality measure and in some languages, of which C and C++ are probably
the
most well-known, when a program compiles successfully for the first
time, the
programmer's problems are just beginning rather than ending.

[..]

2 Safer subsets and noise
The original MISRA C 1998 standard was discussed in detail by [4] from
a
number of points of view. The most pertinent aspect here is the issue
of static
rule induced noise. When a static analysis toolset detects dependence
on an
undefined feature, for example use of a variable which has not been
initialised,
it will issue a warning. Unfortunately, as pointed out by [4], such
rules in
practice fall into three broad categories, A, B.1 and B.2. Of these,
category A
rules are generally stylistic and have no known relationship with
failure. An
example of a category A rule is that all local variables should have a
name
beginning with 'L_'. Category B.1 rules could conceivably be
associated with
failure, (for example the frequently repeated rule that the
'goto' statement shall
not be used), but for which there is still no measurement support as
yet. In
contrast, category B.2 rules are known by measurement to be associated
directly
with failure.

[..]

The goals of MISRA C 2004 The essential goals of the MISRA C 2004
update were:-
1. To remove ambiguity in the wording of some of the rules, (c.f. [4]
for
examples).
2. To correct some of the rules which were actually wrong due to
misunderstandings
of the underlying ISO C standard, ISO 9899:1990.
3. To preserve the relatively simple nature of the wording for better
accessibility
to engineers [Would you trust your life to someone who needs
everything to be dumbed down? -- Colin Paul Gloster, 2007 April
9th. (Not posted until 2007 April 10th.)]
4. To reduce the noise so that the standard was much closer in
transgression
rates to the actual failure data.
[..]
Some of the rules are still ambiguous and the standard
suffers from creating its own words and concepts which were not used
by the
international committee which produced the underlying C standard, ISO
C
9899, (1990). For example, an extraordinarily complex section in MISRA
C 2004
more than 12 pages long introduces a number of concepts such as
"underlying
type" and "complex expression", the latter conflicting with the
introduction of
the complex type in ISO C 9899, (1999). The whole point of this
section is
to attempt to enforce the following long-established reliability
principle in any
programming language:-
Significant bits shall not be lost nor change their signedness (if
relevant) by an implicit conversion.
[..]

[..]

As can be clearly seen, the overall reduction in false positives is a
disappointing
29%, meaning that the real to false positive ratio is still no higher
than about (1/35). This leaves MISRA C 2004 still squarely in the zone
where
correcting all the transgressions is likely to increase the total
number of faults
rather than decrease them according to the argument above and the data
of
[1], and once again it must be concluded that the standard is
unsuitable for
use in an unadulterated form. Very careful and selective rule
deviation will be
necessary to recover any value.

[..]

A further disturbing feature of this analysis is that 5 out of the 7
packages
contained features which unintentionally violated the underlying ISO C
9899
(1990) standard and which the corresponding compilers clearly did not
flag. [..]

[..]

As can be seen, in spite of the complete re-structuring and non-simple
relationship
between the rules in the two versions, the noisiest rules essentially
embody the same concepts. The conclusion is very simple. Unless these
concepts
are refined to be much closer to the underlying failure modes or
excluded
by a deviation policy, both versions of the MISRA C standard are far
too noisy
to be of any real use.
4 Conclusions
In view of the apparent widening influence of the MISRA C standard,
this paper
attempts to assess whether important deficiencies in the original
standard have
been addressed satisfactorily. Unfortunately, they have not and the
important
real to false positive ratio is not much better in MISRA C 2004 than
it was in
MISRA C 1998 and it is unacceptably low in both. [..]

[..] has not solved the most
fundamental problem of MISRA C 1998, viz. that its unadulterated use
as a
compliance document is likely to lead to more faults and not less
because of
the fault re-injection phenomenon first noted by [1]. [..]

[..]

References
[1] E. Adams. Optimising preventive service of software products. IBM
Journal
of Research and Development, 1(28):2.14, 1984.

[..]

[3] L. Hatton. Safer C: Developing software in high-integrity and
safety-critical
systems. McGraw-Hill, 1995. ISBN 0-07-707640-0.

[..]

[6] A. Koenig. C Traps and Pitfalls. Addison-Wesley, 1989. ISBN
0-201-17928-
8.

[..]"


In news:o...@phaedsys.demon.co.uk timestamped Sun, 1 Apr
2007 23:58:16 +0100, Chris Hills <c...@phaedsys.org> posted:
"In article <eup71u$bd5$1...@newsserver.cilea.it>, Colin Paul Gloster
<C...@ACM.org> writes
>As I am responsible, the price of the MISRA C standard is infinitely
>times more than I would pay for such poison that impairs the faculty
>of prudent judgment, impaired to such an extent that people are not
>able to safely drive cars with MISRA C.


Can you justify that statement?"



Maybe. Chris Hills claimed in
news:Y...@phaedsys.demon.co.uk that the MISRA C standard
costs something more than nothing. I would not pay anything for
alcohol and a finite number times that amount is nothing. Infinitity
times nothing might be something more than nothing (but could instead,
still be nothing (dividing a finite number by zero results in an
undefined value)). I looked in some books for you and I did not find a
claim that zero * infinity == finite_number and even trying infinity
== finite_number / zero did not work (something about NaN), but trying
a small number for the divisor can yield a larger finite number so
perhaps some people will conclude that I have disproved an earlier
claim by me. Ah well.

As for what beers can do to brainpower, the literature I have at home
does not include everything I read back in the primitive twentieth
century. It may have been untrue. Blasted propaganda and vested
interests purported to be science. More recently, in 2001, the effects
of such propaganda were still prevalent in a country's police force
such that the police would arrest a person for driving an automotive
carriage while drunk. If we are not careful in this thread, we might
make a participant of this newsgroup unemployed by undermining the
usefulness of a device which scans for alcohol content in one's
breath. Anyway, one person managed to drive a car while drunk in 2001
without being arrested and he crashed into another car, killing
someone. The official assessment was that the killer committed
manslaughter because he was drunk, but maybe someone would like to
prove that it was because the car he used did not have MISRA C. Some
of the story was documented in a magazine called a newspaper, actually
it was called "The Irish Independent". Do not believe everything you
read: think of statements in the media which are not critical of
smoking.
From
WWW.Britannica.com/ebc/article-9354908
:"[..]

alcoholic beverage

[..]

Any fermented liquor, such as [..] beer, [..]

[..] Under the influence of alcohol, the drinker is less alert, less
able to discern objects in the environment, slower in reacting to
stimuli, and generally prone to sleep.

[..]

(C)2007 Encyclopaedia Britannica, Inc."

From
WWW.IngentaConnect.com/search/article?title=tobacco&title_type=tka&year_from=1998&year_to=2007&database=
1&pageSize=20&index=3#avail
:"[..]

  `It's interesting how few people die from smoking': Tobacco industry
  efforts to minimize risk and discredit health promotion 
Author: Smith, Elizabeth A.

Source: European Journal of Public Health, Volume 17, Number 2, 1
April 2007, pp. 162-170(9)

Publisher: Oxford University Press

[..]

Abstract:

Background: It is well known that the tobacco industry has placed
articles in scientific literature to maintain controversy over the
dangers of tobacco use, while claiming that smokers are well-informed
about risk. This study illuminates an industry attempt to directly
undermine popular understanding of the hazards of smoking using an
industry-created organization called Associates for Research in the
Science of Enjoyment (ARISE). Methods: Searches of tobacco industry
documents contained in the Legacy Tobacco Documents Library, British
American Tobacco Documents Library, and British Columbia's Tobacco
Industry documents were performed as well as searches of the
LexisNexis database for news articles on ARISE published between 1989
and 2005. Qualitative analysis focused on industry motives, media
strategies, and rhetorical tactics; quantitative content analysis
focused on media coverage. Results: Between 1989 and 2005, at least
846 articles appeared in the European, Australian, and US press
mentioning ARISE, its members, or its activities. Many of these
articles presented two themes: smoking was a healthful `pleasure', and
health promotion practices, including cessation, were stressful and
unhealthy. Few articles included responses from health advocates,
questioned ARISE's claims, or mentioned its funding. Conclusions:
ARISE successfully planted stories in the press, designed to allay the
health concerns of smokers and to discredit health promotion
information and practices. ARISE's later interest in food suggests
that counterfactual `health' messages on almost any topic could be
promoted similarly, regardless of their implausibility. 
Keywords: mass media; smoking cessation; tobacco industry 

Document Type: Research article 

DOI: 10.1093/eurpub/ckl097

The full text article is available for purchase

$36.29 plus tax

[..]

(C) 2007 Ingenta  [..]"

Does someone want to spend "$36.29 plus tax" on that article to learn
nothing?



Chris Hills wrote:

"  You are disagreeing with many experts."

Truth is not a popularity contest.


">True. MISRA C contains something worth hiding,

What?"

C.




"> and charging money for
>it is one way to deter people from it.

The only people who say this are people like you who decry MISRA-C but
use the cost as an excuse for not having read the standard they are
de-crying."

That is one of many excuses I have. I provide another: no one has
shown that MISRA C has a good feature which none of Ada and VHDL
has.



">The MISRA C standard may cost money for a valid reason.

It cost a lot to develop."


So did the SystemC(R) standard and the newer versions of VHDL and Ada
(without the level of support from the DOD for their initial
versions), yet all of these are available for gratis.

Has MISRA retracted:
"Nonetheless, it should be
recognised that there are other languages available which are in
general
better suited to safety-related systems, having (for example) fewer
insecurities and better type checking. Examples of languages generally
recognised to be more suitable than C are Ada and Modula 2. If such
languages could be available for a proposed system then their use
should be
seriously considered in preference to C."?

If MISRA has not retracted that, then why would I consider MISRA C
instead of Ada? Is MISRA C available for SIL 4 yet (not that I work at
that level myself)?

Regards,
Colin Paul Gloster

I find is sad that in a discussion on high integrity coding  Paul  keeps 
posting using a form which makes it impossible to read who said what.

In article <evegjr$gn7$1...@newsserver.cilea.it>, Colin Paul Gloster 
<C...@ACM.org> writes
>I do not know which of the 29 page pitfalls paper and the book upon
>which it was based W. Wesley Groleau referred to, and I confess I used
>to not remember this email very well (I thought he wrote about Les
>Hatton's "Safer C" before I checked) but nothing from an apologist for
>MISRA C in this thread so far has been even a hint that MISRA C is
>even at least as good as Ada.

No one said MISRA-C was as good as Ada.

>In news:o...@phaedsys.demon.co.uk timestamped Sun, 1 Apr
>2007 23:58:16 +0100, Chris Hills <c...@phaedsys.org> posted:
>"In article <eup71u$bd5$1...@newsserver.cilea.it>, Colin Paul Gloster
><C...@ACM.org> writes
>>As I am responsible, the price of the MISRA C standard is infinitely
>>times more than I would pay for such poison that impairs the faculty
>>of prudent judgment, impaired to such an extent that people are not
>>able to safely drive cars with MISRA C.
>
>
>Can you justify that statement?"
>
>Maybe. Chris Hills claimed in
>news:Y...@phaedsys.demon.co.uk that the MISRA C standard
>costs something more than nothing. I would not pay anything for
>alcohol and a finite number times that amount is nothing.

I did not claim that at all you are miss attributing.

> Infinitity
>times nothing might be something more than nothing (but could instead,
>still be nothing (dividing a finite number by zero results in an
>undefined value)). I looked in some books for you and I did not find a
>claim that zero * infinity == finite_number and even trying infinity
>== finite_number / zero did not work (something about NaN), but trying
>a small number for the divisor can yield a larger finite number so
>perhaps some people will conclude that I have disproved an earlier
>claim by me. Ah well.

You do not appear to be coherent.


>Chris Hills wrote:
>"  You are disagreeing with many experts."
>Truth is not a popularity contest.

True but where the majority of experts lean one way and a few 
non-experts the other I know which way I would prefer.

>">True. MISRA C contains something worth hiding,
>What?"
>C.

C is in title. What is MSRA-C hiding?


>"> and charging money for
>>it is one way to deter people from it.
>
>The only people who say this are people like you who decry MISRA-C but
>use the cost as an excuse for not having read the standard they are
>de-crying."
>
>That is one of many excuses I have. I provide another: no one has
>shown that MISRA C has a good feature which none of Ada and VHDL
>has.

Ada and VHDL are different tools for use in different places.

>">The MISRA C standard may cost money for a valid reason.
>It cost a lot to develop."
>
>So did the SystemC(R) standard and the newer versions of VHDL and Ada
>(without the level of support from the DOD for their initial
>versions), yet all of these are available for gratis.

These are completely different situations you appear blinded by your own 
religion


>Has MISRA retracted:
>"Nonetheless, it should be
>recognised that there are other languages available which are in
>general
>better suited to safety-related systems, having (for example) fewer
>insecurities and better type checking. Examples of languages generally
>recognised to be more suitable than C are Ada and Modula 2. If such
>languages could be available for a proposed system then their use
>should be
>seriously considered in preference to C."?
>
>If MISRA has not retracted that, then why would I consider MISRA C
>instead of Ada?

Because Ada and the relevant tools are not available for many targets.

Why did the use C++ instead of Ada for the JSF?  Why did thety bas the 
JSF++ standard on MISRA-C?

>Is MISRA C available for SIL 4 yet (not that I work at
>that level myself)?

MISRA-C makes no reference to suitability as you well know. Unless of 
course your arguing for your "religion" whilst not having read MISRA-C



-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c...@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris Hills wrote:
> In article <V...@eisner.encompasserve.org>, Simon Clubley 
> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes
>> The argument, as given by ACT, is that the GCC Ada implementation 
>> requires
>> a runtime library, which is included in a program's executable.
> 
>> BTW, as to your question yesterday about Ada in safety critical work,
>> are you aware of what Praxis are doing with SPARK, which is an annotated
>> version of Ada ?
> 
> I think it was me who asked about the use of the ACT/GCC Ada  for safety 
> critical work. I am well aware to what Praxis are doing and it is used a 
> lot in safety critical.
> 
> My comment was if the GCC version was any use for high integrity projects?
> 
> 

As Simon, I have no specific data points here (I haven't even used Ada 
for anything more than brief tests).  But here are a couple of things to 
get you started:

AdaCore are in many ways a typical open source company.  The core of 
their products (in this case, their development and contributions to Ada 
support for gcc) is open source and freely available - lots of people 
can use it, and hopefully that will increase the testing and feedback. 
For professional use, they make packaged, supported, tested, and (I 
don't know the details here) perhaps certified toolkits, available at a 
cost.  In particular, they have a product:

http://www.adacore.com/home/gnatpro/safety-critical


As a second example, RTEMS was originally "Real Time Executive for 
Missile Systems", and is heavily based around using gnat for Ada (and 
gcc for C).  I expect being "safe" is rather important in missile 
control, and I'm sure the company behind RTEMS, OAR Corp., will happily 
give you information and a quote for a safety certified build of RTEMs 
and its gcc-based tools.


Testing, certifying and supporting tools for high integrity development 
is expensive - it's not something standard, downloadable gcc can provide 
unless you are willing to do the testing and certification yourself. 
But there is no reason whatsoever to think that gcc and friends are not 
safe for critical use (for mature and stable ports) - it's just that you 
must pay someone to do the testing and certification that you need, and 
there are several companies who provide exactly that service (for C, 
C++, Ada, and probably other languages).  This is no different from 
buying safety-certified compilers from Green Hills, Metrowerks, or 
anyone else - it's just that since these compilers cost so much to start 
with, buyers *expect* the testing and certification.

Chris Hills wrote:
> In article <oLSPh.494$r...@newsfe1-gui.ntli.net>, ChrisQuayle 
> <n...@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
> 

Isn't that the project which overran its development costs by several 
hundred percent, almost entirely due to software costs?  And there are 
several countries dropping out, or threatening to do so, because they 
can't get access to the software in question?


> Incidentally JSF++ is based on MISRA-C:1998

David Brown <d...@westcontrol.removethisbit.com> writes:

> Chris Hills wrote:
>> In article <oLSPh.494$r...@newsfe1-gui.ntli.net>, ChrisQuayle
>> <n...@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
>>
>
> Isn't that the project which overran its development costs by several
> hundred percent, almost entirely due to software costs?  And there are
> several countries dropping out, or threatening to do so, because they
> can't get access to the software in question?

See, that just goes to show. *Always* insist on your fighter aircraft
firmware being GPL.

-- 

John Devereux

In article <461b53f3$0$24628$8...@news.wineasy.se>, David Brown 
<d...@westcontrol.removethisbit.com> writes
>Chris Hills wrote:
>> In article <oLSPh.494$r...@newsfe1-gui.ntli.net>, ChrisQuayle 
>><n...@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
>>
>
>Isn't that the project which overran its development costs by several 
>hundred percent, almost entirely due to software costs?

Quite probably. My understanding is that C++ was used instead of Ada 
because of the lack of Ada programmers available. (They needed 30,000 SW 
people)

Personally I would have though it would have been more cost effective to 
train a bunch of SW engineers on Ada in the environment they were going 
to use.  Also you could train on the coding standard/style guide you 
wanted and had them all coding the same way from day 1 with no 
preconceived ideas on style  that usually  cause problems.


>And there are several countries dropping out, or threatening to do so, 
>because they can't get access to the software in question?

That has nothing to do with C++ or Ada. More to do with US paranoia on 
SECURITY AND THE END OF CIVILISATION AS WE KNOW IT! . The JSF++ standard 
was initially not released on security grounds! It was then released 
with bits edited out!

However enough people know what was in both versions so that most people 
know what was edited out of the public version.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c...@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <8...@cordelia.devereux.me.uk>, John Devereux 
<j...@THISdevereux.me.uk> writes
>David Brown <d...@westcontrol.removethisbit.com> writes:
>
>> Chris Hills wrote:
>>> In article <oLSPh.494$r...@newsfe1-gui.ntli.net>, ChrisQuayle
>>> <n...@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
>>>
>>
>> Isn't that the project which overran its development costs by several
>> hundred percent, almost entirely due to software costs?  And there are
>> several countries dropping out, or threatening to do so, because they
>> can't get access to the software in question?
>
>See, that just goes to show. *Always* insist on your fighter aircraft
>firmware being GPL.

How does that help on an aircraft?


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c...@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In news:2...@phaedsys.demon.co.uk timestamped Tue, 10 Apr
2007 08:25:32 +0100, Chris Hills <c...@phaedsys.org> posted:
   "[..]

   No one said MISRA-C was as good as Ada.

   [..]"

Thank you for the tip.


In article <evegjr$gn7$1...@newsserver.cilea.it>, Colin Paul Gloster
<C...@ACM.org> writes
   "[..]

   >Chris Hills wrote:
   >"  You are disagreeing with many experts."
   >Truth is not a popularity contest.

   True but where the majority of experts lean one way and a few
   non-experts the other I know which way I would prefer."

I do not agree with everything Les Hatton has said. Do you have a
refutation of his criticisms of MISRA C 2004?


    ">">True. MISRA C contains something worth hiding,
    >What?"
    >C.

    C is in title. What is MSRA-C hiding?"

Okay, you have got me there.


    "[..]
    >
    >[..] people like you who decry MISRA-C but
    >use the cost as an excuse for not having read the standard they are
    >de-crying."
    >
    >That is one of many excuses I have. I provide another: no one has
    >shown that MISRA C has a good feature which none of Ada and VHDL
    >has.

    Ada and VHDL are different tools for use in different places."

They can be used in the same places sometimes. VHDL is used in cars. In
news:es4dl5$ve2$1...@newsserver.cilea.it I mentioned various works
related to targets with overlapping relevance to Ada and VHDL, and I
was clearly not the first to do so.

CynLib; SpecC; Cx (with "x" written in superscript); HardwareC;
Handel-C; Esterel C; CLevelDesign; CDL (C-Development Language and
later Chip Design Language and CDL TM(TradeMark)); CARTE; CATAPULT C;
DIME-C; IMPULSE C; MITRION C; NAPA C; SA-C; and STREAMS C are various
labels which have been used to mention C(-like things) applied to hardware.


Chris Hills wrote:
   "[..]

   Why did the use C++ instead of Ada for the JSF?  Why did thety bas the
   JSF++ standard on MISRA-C?"

I do not know.


Chris Hills wrote:
   ">Is MISRA C available for SIL 4 yet (not that I work at
   >that level myself)?

   MISRA-C makes no reference to suitability as you well know. Unless of
   course your arguing for your "religion" whilst not having read MISRA-C"

Perhaps I had known that sometime, but I am not an expert on SIL nor
MISRA, and I did not know that "MISRA-C makes no reference to suitability [..]"
when I wrote that. WWW.MISRA.org.UK/intro.htm contains:
"[..]

The MISRA Guidelines provide important advice to the automotive
industry for the creation and application of safe, reliable software
within vehicles.

[..]"


Thank you for replying, it is appreciated and was a surprise.

Regards,
C. P. G.

Chris Hills wrote:
> In article <8...@cordelia.devereux.me.uk>, John Devereux 
> <j...@THISdevereux.me.uk> writes
>> David Brown <d...@westcontrol.removethisbit.com> writes:
>>
>>> Chris Hills wrote:
>>>> In article <oLSPh.494$r...@newsfe1-gui.ntli.net>, ChrisQuayle
>>>> <n...@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
>>>>
>>>
>>> Isn't that the project which overran its development costs by several
>>> hundred percent, almost entirely due to software costs?  And there are
>>> several countries dropping out, or threatening to do so, because they
>>> can't get access to the software in question?
>>
>> See, that just goes to show. *Always* insist on your fighter aircraft
>> firmware being GPL.
> 
> How does that help on an aircraft?
> 

I don't think he was being entirely serious...