ARM IDE

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.
 Click to see the full signature
Reply to
FreeRTOS.org
Loading thread data ...

... snip ...

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]: 
 Click to see the full signature
Reply to
CBFalconer

... snip ...

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

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
 Click to see the full signature
Reply to
CBFalconer

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

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     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H
[...]

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:
Reply to
Oliver Betz

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

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

Is that with the same company?

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.

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.

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

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H
[...]

^^^^^^^^

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

I interpreted the word "probably" this way.

Oliver

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

In message , Oliver Betz writes

Intrigued... Can you mail me direct?

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

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.

Usually there is a defined protocol for contacting support. Using some " snipped-for-privacy@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.

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

Reply to
Stefan Reuther

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.)

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

Stefan

Reply to
Stefan Reuther

... snip ...

You can't even say they come close to a suitable test, since you don't have the source available. The closest thing available, AFAIK, is the gnu tests for gcc, which are not ideal because they are intended to test conformance to "GNU C", which in turn is non-standard.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
 Click to see the full signature
Reply to
CBFalconer

A test can at best proof there are bugs, a test can never proof the absence of bugs.

Reply to
Dombo

Most compiler companies recognize the value of tests written by independent third parties. Good compiler tests are both expensive and worth it in terms the value they add to a product. Perennial and Plum Hall are in relative terms modestly priced well written with a clear specific goal. Perennial and Plum Hall tests (they have full source) objectively test language support to specific standards documents.

The GNU tests are are best weak. They lack objective testing of either the language or code generation to a spec or standard.

The important thing about tests is they need to be automated and repeatable. Negative tests are a lot harder to implement but are as important to product development as positive tests

Regards

-- Walter Banks Byte Craft Limited

formatting link

Reply to
Walter Banks

Repeat the request be very clear.

1) Top post 2) 10 or 15 lines (max) to describe problem 3) Use white space 4) Describe solution/requirements 5) Provide contact information with phone number 6) Tool detail: compiler version [ serial/licence number ] 7) Attach supporting material 8) CC sales@. ...

- Make it a newspaper article most import stuff first.

- Everything that is needed is seen as soon as the email opens.

- No guessing. "It is broken", is not a technical term support groups understand. Be clear point to the failure specifically by address or phrase.

- Let support know about deadlines or other extenuating circumstances.

- Be polite support will likely respond in kind. It reinforces your objective to resolve a support problem.

Regards

-- Walter Banks Byte Craft Limited

formatting link

Reply to
Walter Banks

You omitted "publishable".

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
 Click to see the full signature
Reply to
CBFalconer
[...support quality...]

Ack. But "no marketing departement hiding developers from the users" is no quarantee that things will be corrected. Even developers can be uninterested, overloaded etc., and money (support contract) can (!) improve your position.

There are tons of long standing bugs in OSS.

I see no clear indication that OSS is better in this respect. I have seen any combination of good/bad support with open and closed source software.

Oliver

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

BTDT, no guarantee it helps. But it's frustrating if you do it repeatedly because it's a lot of wasted work.

Slightly off-topic but similar: I have been sending so many reports about silicon and documentation errors to a uC manufacturer. Always hard to convince first level support that it is a bug. After being successful there, with some luck, it's published not sooner than one year later.

Oliver

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

This is true. As I have said before developers are often less interested in talking to users and less tolerant than the support people

Really@ I thought OSS bugs were fixed in minutes because everyone has the source. You mean it is no better than commerical software. Just a hell of a lot less control and lots of amended (non-standard and untested) versions floating around all over the place,.

I agree. The difference is the commercial packages have more of an incentive to give good support. It they give bad support they loose their job of the company looses sales and they loose their job etc

BTW Do remember that most of these support people are software people just like you are..... Usually just as qualified and usually more experienced in their tools than you are.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H
[...support quality...]

not necessarily true. There _are_ less critical customers with lots of money and certain decision structures.

I don't understand the joke behind this. After all, I'm more a hardware guy, not even "mainly digital" but also analog and power.

Oliver

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

[...]

This matches our experience surprisingly close.

Once you got through to the developers or even just the application engineers, things get a lot easier.

Stefan

Reply to
Stefan Reuther

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.