Are data type compiler-dependent or target dependent

[Nominal Animal]

So, for me, I have the feeling that it's more an ideological problem, especially for those who don't care about debuggers.

Not in my case; the opposite.  If ICE or provably correct operation is desirable or required (like for life-saving equipment), then proper tools need to be available; and tools that only get part way there are just not good enough for me.  You might say I care too much...

Unfortunately, I'm not good enough with compilers to push a dominant change into Gcc or LLvm or something; myC is 60% based on lcc-v4, I am not able to write a C compiler from scratch, and the result requires people to adapt their coding style, that is *the* serious problem because most C programmers won't.

This is absolutely true.  A bit over a decade or so ago I did spend a couple of years (not continuously or every day, but you know, whenever I could) to push some fixes upstream to GCC and gfortran, and it being still the era of "Unless you have a doctorate in CS and peer-reviewed papers on compiler theory, we do not deign to respond to your posts, you insignificant loser" -type core GCC developers, it really put me off working on any kind of compiler..  The people at GCC are much different now, and there is even clang, but porting a toolchain to a new (old) architecture takes a lot of careful work, and has a steep learning curve.

I definitely would not want to have to port any GCC or clang frontends or backends to a new architecture, that's for sure.  It's just that if I were to start working on safety-critical code, that's pretty much what I feel I personally would have to do, because I just do not believe any ruleset or small tweak of C syntax can make it sufficiently safe, even if it were to fulfill some industry rulesets.

In particular, the kinds of problems I end up spending most time with, are 1) emergent behaviour arising from complex interactions between subsystems and mechanisms, and 2) efficient and effective interfaces (and abstractions at the correct complexity level); not typos or memory management or buffer overrun or misalignment type things.

[DiTBho]

I definitely would not want to have to port any GCC or clang frontends or backends to a new architecture

Yup, I have in mind MIPS4++ and MIPS5, but also HPPA2 if Gcc will ever drop the support.
"just in case" plan 

that's for sure.  It's just that if I were to start working on safety-critical code, that's pretty much what I feel I personally would have to do, because I just do not believe any ruleset or small tweak of C syntax can make it sufficiently safe, even if it were to fulfill some industry rulesets.

Under DO178, whatever you do, the main QA rule tells you that everything is always subjected to several verification and inspections at different QA levels.

draft -> engineering version -> QA approved level1 -> QA approved level2 -> product -> product revision -> ...

This is software life-cycle, an it's regulated by DO178.

It's not a matter of being sufficiently safe at the compiled level, things like myC cannot guaranty that, even official tool like Stood cannot guaranty that, but rather a matter of having debugging sufficiently facilitated at the self-instrumentation level so you can run more testing activities within the same budget and time.

$200/person per day
8-9 hours per day

the more you can test, more  bugs you can find

my AI-ICEs cost ~$20 per day(1)

(1) talking about 5 years mortgage for the company to pay the equipment
$20.000 total cost, 200 days ~ 5 years

[Nominal Animal]

It's not a matter of being sufficiently safe at the compiled level, things like myC cannot guaranty that, even official tool like Stood cannot guaranty that, but rather a matter of having debugging sufficiently facilitated at the self-instrumentation level so you can run more testing activities within the same budget and time.

Right.  In other words, you don't do myC because you think it fixes problems inherent in C, but because it fits better into the (human) verification framework around the target implementations. 

The point about SPARK/Ada is that verifiability is one of its design goals, and the existing tools –– I believe, not having used them myself –– have rather extensive verification and validation options compared to what is possible with C.  Having tools that can tear down the code into Hoare logic that is then passed to automated theorem provers, and find out its fundamental properties or deficiencies, is pretty mind-bending to me...  (It's exactly the kind of complex interactions that that kind of analysis can reveal that gives me most pause nowadays, like I already mentioned; not the "easy" stuff like memory management.)
Not using them for safety critical stuff, and "just settling" with MISRA and similar rulesets, seems like taking the easy way out to me, though.  You know, like choosing not to spend X to reduce the risk of loss of life by Y, because of commercial or business reasons.

Then again, I'm the last person anyone should consult about business matters! 

[SiliconWizard]

Well. Relying on debugging for proving the safety and correctness of code is possibly understandable in some situations, but definitely not the approach most people implementing safety-criticial stuff would like to take. Eek. Testing and "formal" proofing are two different things. They are complementary. But focusing on debugging sounds pretty horrible generally speaking.

MISRA is a mixed bag. While some of its rules are common sense or just good practice, others are like removing as much from C as possible while keeping it Turing-complete.
It's sometimes too close to "let's forbid additions, since additions in C can overflow". Just barely exaggerating. Yeah OK.

The thing with Ada is that, apart from gcc (which is already a good thing), tools are not abundant and tend to be expensive. And while it *can* be used for "small" targets, it's nowhere near as efficient (neither performance- nor code size-wise) as C. So this is often a tough choice. Not to mention it's basically taught almost nowhere these days, so Ada developers are either pretty old by now or just self-taught.

[DiTBho]

Right.  In other words, you don't do myC because you think it fixes problems inherent in C, but because it fits better into the (human) verification framework around the target implementations. 

Yup, that's the purpose