Chris Hills wrote:
> In article <4...@yahoo.com>, CBFalconer
>> Paul Carpenter wrote:
>>> c...@yahoo.com "CBFalconer" wrote:
>>>> Chris Hills wrote:
>>>
>>... snip ...
>>>>
>>>>> I think most automotive things have moved to C now.
>>>>
>>>> I certainly hope not.  That in itself would show gross disregard
>>>> for safety, and could be the grounds for all sorts of lawsuits
>>>> and punitive awards.  Ada would be more reasonable.
>>>
>>> Which is why MISRA-C was formulated and the necessary validator
>>> tools created and Safety level criteria to meet.
>>
>> Are you seriously suggesting that Misra-C can rival Ada in
>> security?  All it can do is mitigate some of the more common
>> failings and misuse of C.  I have never read it, since they seem
>> to want real money for a copy.
> 
> Since you have not read it I would suggest heresy is inadmissible.
> Beside, my friend said it was perfect.
> 
> What is wrong with paying for a copy. You buy other tools I assume.

As I look around this machine I have a hard time finding anything
in regular use that required actual money.  Apart from the OS,
which came with the hardware, the only things I can think of are
the editor (Textpad), the shell (4dos), and the printer utility
(fineprint).  I am renowned for my tight grasp on the currency of
the realm and the size of the moths that breed in my wallet.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

CBFalconer wrote:
> Chris Hills wrote:

>>
>>What is wrong with paying for a copy. You buy other tools I assume.
> 
> 
> As I look around this machine I have a hard time finding anything
> in regular use that required actual money.  Apart from the OS,
> which came with the hardware, the only things I can think of are
> the editor (Textpad), the shell (4dos), and the printer utility
> (fineprint).  I am renowned for my tight grasp on the currency of
> the realm and the size of the moths that breed in my wallet.

Hold on to those tools -- they'll be valuable antiques any day now.

Ed

On Saturday, in article <4...@yahoo.com>
     c...@yahoo.com "CBFalconer" wrote:
>Paul Carpenter wrote:
>> c...@yahoo.com "CBFalconer" wrote:
>>> Chris Hills wrote:
>>
>... snip ...
>>>
>>>> I think most automotive things have moved to C now.
>>>
>>> I certainly hope not.  That in itself would show gross disregard
>>> for safety, and could be the grounds for all sorts of lawsuits
>>> and punitive awards.  Ada would be more reasonable.
>> 
>> Which is why MISRA-C was formulated and the necessary validator
>> tools created and Safety level criteria to meet.
>
>Are you seriously suggesting that Misra-C can rival Ada in
>security?  All it can do is mitigate some of the more common

 ^^^^^^^^^

Please make up your mind about what you want to rant about, for safety
critical applications like car brakes and other industries, especially for
STANDALONE items, safety bodies and other accreditation and testing
facilities have stipulated MISRA-C for SAFETY as PART of the safety
design and testing. It is only one small part of the whole picture.

Security is only one part of the safety design.

Please stop moving your targets, to me you are getting boring.

>failings and misuse of C.  I have never read it, since they seem to
>want real money for a copy.

Well how do you know whether that at least the automotive and some
parts of the medical industry are wrong then.

You are starting to sound more like a troll.

-- 
Paul Carpenter          | p...@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>;    PC Services
<http://www.gnuh8.org.uk/>;              GNU H8 & mailing list info
<http://www.badweb.org.uk/>;             For those web sites you hate

On Sat, 05 Mar 2005 23:44:38 GMT, Darin Johnson <darin_@_usa_._net>
wrote:

>Paul Keinanen <k...@sci.fi> writes:
>
>> >Not really.  Someone has to write all the code that appears between
>> >a system reset and the call to main().  
>> 
>> Just put the address of the init routine (written in some high level
>> language) into the reset vector of the processor.
>
>You have a lot of examples that require special additions to
>compilers.  Pseudo variables for registers, init pragmas, etc.
>That's a lot of effort on the compiler developers part just
>because some programmers want to avoid using assembler and
>inlined assembler.  

The Borland Turbo-C had most of these features two decades ago and
many other compilers these days have at least some of these features. 
  
>Each variant of an instruction set would need a new variant of the compiler, 

Is this really a problem, since each variant of an instruction set
would require a new variant of the code generator anyway :-).

>and maybe each RTOS would need a compiler variant.  

Not really. The only thing that the compiler must be able to do is to
save/restore the _application_ context i.e. registers used by the
programming language. Much of this would already be required to
implement the interrupt pragma. The only part that might need to be
written in assembler is the actual task switch, when the task pointer
is switched, but even this could be doable in a high level language,
provided that you can force the compiler to generate only implicit
register references, as I suggested with the init code.

>And I don't think it'll be all that soon before compilers can deal
>efficiently with some of these issues.  The compiler writers aren't
>spending their time worried about optimizing accesses to memory mapped
>registers.

These are perfect candidates for in-line assembly.

IMHO, the proper way to use in-line assembly is to use it for a linear
sequence of instruction (or perhaps for a single hardware specific
loop), but to do the program flow control things (e.g. if, for, while
etc.) in a high level language, thus, the program remains quite
readable.

I have nothing against assembly programming as such, I have written
quite a lot of assembly work in the 1970's, but the problem with most
assembly programs is that they are hard to read and hence hard to
maintain. Of course the same applies to FORTRAN IV and earlier, in
which the only control structure was the DO loop and all the other
flow controls had to be handled by GOTOs.  

Writing assembly and such old style FORTRAN programs is not a problem,
maintaining them is. Of course, this will give some job security :-),
but sooner or later you would like to do something new, unless of
course, you are just going to retire.

Paul
   

In article <4...@yahoo.com>, CBFalconer
<c...@yahoo.com> writes
>Chris Hills wrote:
>> In article <4...@yahoo.com>, CBFalconer
>>> Paul Carpenter wrote:
>>>> c...@yahoo.com "CBFalconer" wrote:
>>>>> Chris Hills wrote:
>>>>
>>>... snip ...
>>>>>
>>>>>> I think most automotive things have moved to C now.
>>>>>
>>>>> I certainly hope not.  That in itself would show gross disregard
>>>>> for safety, and could be the grounds for all sorts of lawsuits
>>>>> and punitive awards.  Ada would be more reasonable.
>>>>
>>>> Which is why MISRA-C was formulated and the necessary validator
>>>> tools created and Safety level criteria to meet.
>>>
>>> Are you seriously suggesting that Misra-C can rival Ada in
>>> security?  All it can do is mitigate some of the more common
>>> failings and misuse of C.  I have never read it, since they seem
>>> to want real money for a copy.
>> 
>> Since you have not read it I would suggest heresy is inadmissible.
>> Beside, my friend said it was perfect.
>> 
>> What is wrong with paying for a copy. You buy other tools I assume.
>
>As I look around this machine I have a hard time finding anything
>in regular use that required actual money. 

NOT so

What about the bus specs? 

> Apart from the OS,
>which came with the hardware, the only things I can think of are
>the editor (Textpad), the shell (4dos), and the printer utility
>(fineprint).  I am renowned for my tight grasp on the currency of
>the realm and the size of the moths that breed in my wallet.

Fare enough. 

However you have not given any reason why MISRA-C should be free. There
were costs in producing it.

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

Chris Hills wrote:
>
... snip ...
> 
> However you have not given any reason why MISRA-C should be free.
> There were costs in producing it.

There were costs in producing the specifications for Pascal and for
Ada, not to mention the costs of implementing them.  IMO both are
superior to MISRA in catching errors, yet both are available free
of charge.  The result is that I (and I suspect others) have very
little urge to pay for MISRA specifications.  I also conjecture
that I can write sounder C code while ignoring MISRA than can most
while adhering to MISRA.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

In article <4...@yahoo.com>, CBFalconer
<c...@yahoo.com> writes
>Chris Hills wrote:
>>
>... snip ...
>> 
>> However you have not given any reason why MISRA-C should be free.
>> There were costs in producing it.
>
>There were costs in producing the specifications for Pascal and for
>Ada, not to mention the costs of implementing them.  IMO both are
>superior to MISRA in catching errors, yet both are available free
>of charge.

So? Who paid costs for Pascal and ADA. BTW I thought the US Gov.
bankrolled Ada

Will you sump up the costs for doing MISRA-C so others can have it free?


>  The result is that I (and I suspect others) have very
>little urge to pay for MISRA specifications.

OK... you won't pay for the tools of your trade. 

>  I also conjecture
>that I can write sounder C code while ignoring MISRA than can most
>while adhering to MISRA.

Please prove that.  IE prove that in a way that would be usable in a
court of law. For example:-

MISRA-C has been approved by the SAE and JSAE and all the main auto
manufacturers. I can run automatic test tools on C code to show it is
MISRA-C complaint.  The contract requires MISRA-C compliance. 
Sorted.

Your option is? 
BTW You option must be as cost effective as the MISRA-C option is. 



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

Chris Hills wrote:
> <c...@yahoo.com> writes
>
... snip ...
> 
>>  The result is that I (and I suspect others) have very
>> little urge to pay for MISRA specifications.
> 
> OK... you won't pay for the tools of your trade.
> 
>> I also conjecture that I can write sounder C code while ignoring
>> MISRA than can most while adhering to MISRA.
> 
> Please prove that.  IE prove that in a way that would be usable in a
> court of law. For example:-

You did note that I said conjecture?

> 
> MISRA-C has been approved by the SAE and JSAE and all the main auto
> manufacturers. I can run automatic test tools on C code to show it is
> MISRA-C complaint.  The contract requires MISRA-C compliance.
> Sorted.
> 
> Your option is?
> BTW You option must be as cost effective as the MISRA-C option is.

But I have no contract or other reason, apart from curiousity, to
investigate MISRA.  Whether or not some code is MISRA compliant
means very little to me.  If it uses C I expect it is either so
emasculated as to be fairly pointless, or has the fundamental
faults of C.  The moment I can create and use an arbitrary pointer
into the midst of some object reliability is out the window.

Of course I may be totally mistaken.  Without actual knowledge of
what the thing really is I cannot be sure, only opinionated.  What
I do know is that C (and assembly) are unsafe languages without any
real hope of being made both 'safe' and recognizable.  'Safe' is a
relative term anyhow, closely related to frozen flying pigs in
hell.  To me attempts to so enhance C are isomorphic to finding the
largest prime or an exact rational solution to x*x == 2.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

CBFalconer wrote:

>> MISRA-C has been approved by the SAE and JSAE and all the main auto
>> manufacturers. I can run automatic test tools on C code to show it is
>> MISRA-C complaint.  The contract requires MISRA-C compliance.
>> Sorted.
>> 
>> Your option is?
>> BTW You option must be as cost effective as the MISRA-C option is.
> 
> But I have no contract or other reason, apart from curiousity, to
> investigate MISRA.  

[%X]

Curiosity is OK at times. If you need to know what the MISRA-C guidelines 
suggest for making C a safer programming language then you should get hold 
of the pdf version at the very least (it is cheap enough, though not free).

> Of course I may be totally mistaken.  Without actual knowledge of
> what the thing really is I cannot be sure, only opinionated.

I consider that making the investment in a copy would enable you to argue 
your point of view with much more authority.

> What
> I do know is that C (and assembly) are unsafe languages without any
> real hope of being made both 'safe' and recognizable.  'Safe' is a
> relative term anyhow, closely related to frozen flying pigs in
> hell.  To me attempts to so enhance C are isomorphic to finding the
> largest prime or an exact rational solution to x*x == 2.

All programming languages are unsafe without a decent development process 
behind them to support the design decisions being made. However, with such 
a decent development process in place that applies tests and reviews at 
frequent intervals, then a safe system can be produced with any language. 
It is true that you may only use a subset of some of the languages but 
selecting the subset is part of the development process.

-- 
********************************************************************
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. http://www.electric-boat-association.org.uk/
********************************************************************

Paul Keinanen <k...@sci.fi> writes:

> >Each variant of an instruction set would need a new variant of the compiler, 
> 
> Is this really a problem, since each variant of an instruction set
> would require a new variant of the code generator anyway :-).

Sort of, but not really.  Compilers don't do so well here as I've
noticed.  Ie, the Metrowerks PowerPC compiler allowed you to tell it
that you were on an MPC860, but it still insisted on unrolling loops
so that they'd no longer fit into the instruction cache.  I'm assuming
it essentially just had one code generator that didn't change much,
and telling it what cpu you head merely enabled different
pseudo-variables.

> >The compiler writers aren't
> >spending their time worried about optimizing accesses to memory mapped
> >registers.
> 
> These are perfect candidates for in-line assembly.

But I thought you were arguing that assembly wouldn't be necessary
in the future, and wouldn't that include inline-assembly also?

> I have nothing against assembly programming as such, I have written
> quite a lot of assembly work in the 1970's, but the problem with most
> assembly programs is that they are hard to read and hence hard to
> maintain.

Of course.  But aren't we just talking about small fragments of code
here?  Inline-assembler, context switches, bootstrapping, etc?

-- 
Darin Johnson
    "You used to be big."
    "I am big.  It's the pictures that got small."