ARM IDE

"David Brown" <david.brown@hesbynett.removethisbit.no> wrote in message 
news:EtCdnXG9DbA5TbTUnZ2dnUVZ8vqdnZ2d@lyse.net...

> If the safety-critical software developers are doing their jobs, then bugs 
> in the compiler and library will be spotted during *their* testing.

Absolutely - this is exactly what I said ages ago in this thread (which is 
just going round in circles).  Language compliance testing is just that, 
language compliance testing.  The compiler can pass standards compliance 
testing and still have bugs in its code generation (the example I gave of an 
interrupt stack frame) so the fact it passes language compliance testing 
does not lessen the need to test your code.  After all, the engineers might 
have a different idea to what the standard says as the compliance test 
writers.

If you app is really that safety critical then your test coverage criteria 
should be strict enough that your testing finds the bugs making the compiler 
choice incidental.  Testing requirements to object code, that is, 
requirements to the actual output of the compiler, means your tests can show 
your code is correctly fulfilling its requirements whether the compiler is 
compliant to the standard or not - it (almost) doesn't matter - its whether 
your implementation matches the requirements that matters (the requirements 
are probably wrong though ;o)

I'm not saying there is no value in language compliance testing, but it is 
not a magic bullet that makes much difference to anything else you do in the 
development other than show the required due diligence, use of state of the 
art, etc.

-- 
Regards,
Richard.

+ http://www.FreeRTOS.org Designed for Microcontrollers
17 official architecture ports, more than 6000 downloads per month.

+ http://www.SafeRTOS.com
Certified by T&#4294967295;V as meeting the requirements for safety related systems.

Chris H wrote:
> 
... snip ...
> 
> Often porting the code to a more modern compiler is a lot less
> hassle than trying to rebuild a compiler that is that old.

FYI the C standard has not changed seriously since 1989.  The only
serious change was in 1999, but is generally (but not totally)
backward compatible.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

Chris H wrote:
> Stefan Reuther <stefan.news@arcor.de> writes
>
... snip ...
> 
>> Maybe if you buy "100% ANSI C" products.
> 
> I think you mean ISO 9899 not ANSI C...... but we don't need to
> be precise :-)

FYI they are identical.  ANSI has adopted the ISO C standard.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

In message <EtCdnXG9DbA5TbTUnZ2dnUVZ8vqdnZ2d@lyse.net>, David Brown 
<david.brown@hesbynett.removethisbit.no> writes
>Chris H wrote:
><snip>
>> Your  "confident" assurances amount to what? Not a lot really? You 
>>expect me to bet my life and the lives of others on your say so?
>>
>
>Yes, that is *exactly* what people developing safety critical systems 
>expect you to do.

Actually not.  They give the proofs. Also the testers are independent to 
the developers.  Both need to be qualified and experienced.

>The compiler is just one of the many tools used by one of the many 
>developers during the design of one of the many parts of any given 
>safety critical system.  Whether the particular compiler is Plum Hall 
>tested or not is a tiny drop in the ocean of the required careful 
>development procedures and the required testing.
>
>You seem to be of the impression that it is a critical part,

No all the way through I have said it is only a part of the testing. 
There are a lot of tests required. Lots of other information is also 
needed.
The Perennial or Plum Hall are the tests for the C language conformance. 
BTW In some ways I think the Perennial is better than the Plum Hall.

However as I have said all the way through they are only part of the 
validation.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris H wrote:

[...]

>Usually If you can't get past first line support there is a reason for 
>that. The developers probably are aware of you and told support they 
>don't want to talk to you.   Sorry if that hurts.

I'm afraid your knowledge about this topic is somewhat limited.

You _can_ find first level support acting as bulwark (but without a
clue).

First level support of one company _still_ tries to deny first my
reports although it happened more than once that they had to admit the
problem in the end or corrected it silently sometimes later. On the
other hand, I have good direct contact to developers skipping first
level support, and I received several free licenses of other products
for reporting bugs/weaknesses and submitting suggestions etc.

So don't assume that someone is incompetent because he can't go past
first level support. And don't assume that developers get the valuable
information from the people talking to the users (support and sales
staff). Communication is bad in many companies.

Please note that this doesn't mean anything about FOSS vs. closed
source. There are also ignorant open source developers.

Oliver
-- 
Oliver Betz, Munich
despammed.com might be broken, use Reply-To:

In message <finki410m8nk5u4n7fpnnjkksdm9rrh60c@z1.oliverbetz.de>, Oliver 
Betz <obetz@despammed.com> writes
>Chris H wrote:
>
>[...]
>
>>Usually If you can't get past first line support there is a reason for
>>that. The developers probably are aware of you and told support they
>>don't want to talk to you.   Sorry if that hurts.
>
>I'm afraid your knowledge about this topic is somewhat limited.

I don't know about that. I deal with a lot of compiler companies. No 
just the ones we sell

>You _can_ find first level support acting as bulwark (but without a
>clue).

Yes. It is possible but not as common as people try and make out,

>First level support of one company _still_ tries to deny first my
>reports although it happened more than once that they had to admit the
>problem in the end or corrected it silently sometimes later. On the
>other hand, I have good direct contact to developers skipping first
>level support, and I received several free licenses of other products
>for reporting bugs/weaknesses and submitting suggestions etc.

Is that with the same company?

>So don't assume that someone is incompetent because he can't go past
>first level support.

I don't. Some of it is how you approach and deal with people.... There 
is one person I have come across who never gets past first line and has 
terrible problems with support from lots of companies... most of it is 
down to the way he talks to them.

He knows what he is doing but his social skills are  so poor he pisses 
people off.

>And don't assume that developers get the valuable
>information from the people talking to the users (support and sales
>staff). Communication is bad in many companies.

This is also true. though hopefully mess so in support. The lead 
developer in one compiler company told me (in a phone call during this 
thread) that he is copied on ALL support queries so he has a view of 
what is going on.

In other places it al goes into a database e that the developers 
review,. However not all companies are as good as this.

>Please note that this doesn't mean anything about FOSS vs. closed
>source. There are also ignorant open source developers.

Quite... We are discussing company dynamics and organisation. This has 
nothing to do with open/closed source.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris H wrote:

[...]

>>>Usually If you can't get past first line support there is a reason for
>>>that. The developers probably are aware of you and told support they
                        ^^^^^^^^
>>>don't want to talk to you.   Sorry if that hurts.
>>
>>I'm afraid your knowledge about this topic is somewhat limited.
>
>I don't know about that. I deal with a lot of compiler companies. No 
>just the ones we sell
>
>>You _can_ find first level support acting as bulwark (but without a
>>clue).
>
>Yes. It is possible but not as common as people try and make out,
>
>>First level support of one company _still_ tries to deny first my
>>reports although it happened more than once that they had to admit the
>>problem in the end or corrected it silently sometimes later. On the
>>other hand, I have good direct contact to developers skipping first
>>level support, and I received several free licenses of other products
>>for reporting bugs/weaknesses and submitting suggestions etc.
>
>Is that with the same company?

Of course not. BTW: The bad example mentioned above doesn't sell
compilers but debuggers.

>>So don't assume that someone is incompetent because he can't go past
>>first level support.
>
>I don't. Some of it is how you approach and deal with people.... There 

I interpreted the word "probably" this way.

Oliver
-- 
Oliver Betz, Munich
despammed.com might be broken, use Reply-To:

In message <cgili4hsrqhq69qtf4r7ksl1rsah5lpln3@z1.oliverbetz.de>, Oliver 
Betz <obetz@despammed.com> writes
>
>>>First level support of one company _still_ tries to deny first my
>>>reports although it happened more than once that they had to admit the
>>>problem in the end or corrected it silently sometimes later. On the
>>>other hand, I have good direct contact to developers skipping first
>>>level support, and I received several free licenses of other products
>>>for reporting bugs/weaknesses and submitting suggestions etc.
>>
>>Is that with the same company?
>
>Of course not. BTW: The bad example mentioned above doesn't sell
>compilers but debuggers.

Intrigued... Can you mail me direct?

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris H wrote:
> Oliver Betz <obetz@despammed.com> writes
>> Chris H wrote:
>> [...]
>>> Usually If you can't get past first line support there is a reason for
>>> that. The developers probably are aware of you and told support they
>>> don't want to talk to you.   Sorry if that hurts.
>>
>> I'm afraid your knowledge about this topic is somewhat limited.
> 
> I don't know about that. I deal with a lot of compiler companies. No
> just the ones we sell

But maybe _because_ you sell. That generates possible revenue.

A mere mortal has bought the compiler, has bought the library, has
bought the support contract. The vendor already has the money. The user
is (often) locked-in that he cannot easily change the vendor. So why
should he be too cooperative?

If I bounce off 1st level, what can I do? (Note that you have carefully
avoided answering my questions in that direction so far.) If you're a
reseller, you can say "so long, thanks for all the fish, never see you
again". If you're deeply locked-in, all you could try is out-of-band
communication through the legal department. This just *cannot* be the
intended way how thinks should work. And it is hard if there is a
country boundary between, let alone an ocean.

>> And don't assume that developers get the valuable
>> information from the people talking to the users (support and sales
>> staff). Communication is bad in many companies.
> 
> This is also true. though hopefully mess so in support. The lead
> developer in one compiler company told me (in a phone call during this
> thread) that he is copied on ALL support queries so he has a view of
> what is going on.

Usually there is a defined protocol for contacting support. Using some
"support@big.company" role account. I would expect that be the way to
establish working communication.

If it only works when you communicate directly with the developers (and
this works most of the time), there's something wrong.

>> Please note that this doesn't mean anything about FOSS vs. closed
>> source. There are also ignorant open source developers.
> 
> Quite... We are discussing company dynamics and organisation. This has
> nothing to do with open/closed source.

One difference with plain OSS (i.e. not pre-packaged OSS with support
contract and price tag) here is that there is no marketing departement
trying to hide the developers from the users. A foo-devel or foo-support
mailing list accepts input from almost everyone.


  Stefan

Chris H wrote:
> In message <EtCdnXG9DbA5TbTUnZ2dnUVZ8vqdnZ2d@lyse.net>, David Brown
>> Chris H wrote:
>>> Your  "confident" assurances amount to what? Not a lot really? You
>>> expect me to bet my life and the lives of others on your say so?
>>
>> Yes, that is *exactly* what people developing safety critical systems
>> expect you to do.
> 
> Actually not.  They give the proofs.

I haven't seen one. And what can such a proof be worth if I still keep
finding bugs in qualified & certified compilers? (The last problem of
that kind, just four hours ago, the linker crashing with a protection
violation, was cured by a reboot. Wow. Cool technology.)

> Also the testers are independent to
> the developers.  Both need to be qualified and experienced.

So are our testers. They just don't test compilers, they test
fully-assembled devices.


  Stefan