## Schrödinger's Code - Undefined behavior in theory and practice

jahboater
Posts: 7203
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

### Re: Schrödinger's Code - Undefined behavior in theory and practice

Paeryn wrote:
Thu Jun 10, 2021 8:03 pm
jahboater wrote:
Thu Jun 10, 2021 7:16 pm

Code: Select all

``````    x = y / 0;
``````
There is no integer representation for infinity.
It doesn't matter that there is no integer representation of infinity since y / 0 doesn't equal infinity. Assuming 5 / 0 did equal inf. then reversing it you'd add up an infinite number of zeros but you'll find that you're still 5 short. Dividing by zero is mathematically undefined, you can't do it, C gets this right in saying it's UB!
I didn't know that!

But the IEEE floating point hardware does return infinity and raises the divide-by-zero exception?

On the other hand, the floating point hardware definitely doesn't like 0.0/0.0 which raises an invalid operation exception.
Not sure what value it returns, probably a NaN.

Heater
Posts: 18373
Joined: Tue Jul 17, 2012 3:02 pm

### Re: Schrödinger's Code - Undefined behavior in theory and practice

jahboater wrote:
Thu Jun 10, 2021 8:14 pm
But the IEEE floating point hardware does return infinity and raises the divide-by-zero exception?

On the other hand, the floating point hardware definitely doesn't like 0.0/0.0 which raises an invalid operation exception.
Not sure what value it returns, probably a NaN.
Wait a minute. How does it make any sense to think of the return value of an operation that has raised an exception to indicate that it cannot make a meaningful result for the operation? Whatever result is therefore meaningless.
Memory in C++ is a leaky abstraction .

Paeryn
Posts: 3311
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

### Re: Schrödinger's Code - Undefined behavior in theory and practice

Arm's fpu (and hence I assume IEEE 754) will return NaN if the numerator and denominator are both zero or both inf. This will flag an FP_InvalidOperation exception.

If the numerator is inf. or the denominator is 0 then the result is +inf. if they have the same sign or -inf. if they have different signs, and an FP_DivideByZero exception is flagged in the case of the denominator being zero.

If the numerator is zero or the denominator is inf. then the result is +0 if both have the same sign or -0 if they have different signs, no exceptions flagged are.

I'm not sure on IEEE's decision to return +-inf. when dividing by zero if the numerator isn't also zero, I assume they had a good reason.
Heater wrote:
Thu Jun 10, 2021 8:29 pm
Wait a minute. How does it make any sense to think of the return value of an operation that has raised an exception to indicate that it cannot make a meaningful result for the operation? Whatever result is therefore meaningless.
The hardware has to return some value, it may be either a best answer should you not care about the exception (the NaN returned above is a quiet NaN in that it can usually propogate through a calculation without signaling more errors) or an indication as to why the exception happened.
She who travels light — forgot something.
Please note that my name doesn't start with the @ character so can people please stop writing it as if it does!

LdB
Posts: 1703
Joined: Wed Dec 07, 2016 2:29 pm

### Re: Schrödinger's Code - Undefined behavior in theory and practice

x = y + z;
That is signed addition and there are multiple things that can happen on different CPU's and DSP's if it rolls
It will remain undefined in C as a common implementation on all CPU cores can't be done they don't have the traps in silicon to do it

Even if the C standard board made the standard the manufacturers of the CPU's won't accept it and ultimately demand their compiler vendors ignore it. Remember the CPU vendor sells us programmers the compiler (one off cost or annual subscription) and ultimately they decide if the standard lives or dies (they already killed a few last year). Microsoft does the same they often ignore C/C++ standards they don't agree with.

That is so easy to write in a defined way it's actually a none issue and I know a few who would ask why is this even getting airtime.

So remember everyone can have good ideas but at the end of the day if you aren't paying you don't get a say

ejolson
Posts: 7619
Joined: Tue Mar 18, 2014 11:47 am

### Re: Schrödinger's Code - Undefined behavior in theory and practice

LdB wrote:
Fri Jun 11, 2021 3:19 pm
x = y + z;
That is signed addition and there are multiple things that can happen on different CPU's and DSP's if it rolls
It will remain undefined in C as a common implementation on all CPU cores can't be done they don't have the traps in silicon to do it

Even if the C standard board made the standard the manufacturers of the CPU's won't accept it and ultimately demand their compiler vendors ignore it. Remember the CPU vendor sells us programmers the compiler (one off cost or annual subscription) and ultimately they decide if the standard lives or dies (they already killed a few last year). Microsoft does the same they often ignore C/C++ standards they don't agree with.

So remember everyone can have good ideas but at the end of the day if you aren't paying you don't get a say
I think there is a little difference between undefined behaviour and implementation defined behaviour as far as the standards document goes. My understanding is that unsigned n=8, 16, 32 and 64-bit arithmetic in C has mandated modulo 2^n wrap around since almost the beginning. It's also worth noting that the standard library in early versions of Unix relied on the same wrap around behaviour for signed integers.

As for standards, before C was a big deal, anyone using the original K&R compiler as a reference would have followed the same for compatibility.

lurk101
Posts: 696
Joined: Mon Jan 27, 2020 2:35 pm
Location: Cumming, GA (US)

### Re: Schrödinger's Code - Undefined behavior in theory and practice

LdB wrote:
Fri Jun 11, 2021 3:19 pm
Even if the C standard board made the standard the manufacturers of the CPU's won't accept it and ultimately demand their compiler vendors ignore it. Remember the CPU vendor sells us programmers the compiler (one off cost or annual subscription) and ultimately they decide if the standard lives or dies (they already killed a few last year). Microsoft does the same they often ignore C/C++ standards they don't agree with.
I seriously doubt any CPU manufacturer or compiler vendor would ignore what has long been considered standard integer representation and operation.
How to make your arguments stronger? Longer is not the answer.

ejolson
Posts: 7619
Joined: Tue Mar 18, 2014 11:47 am

### Re: Schrödinger's Code - Undefined behavior in theory and practice

lurk101 wrote:
Fri Jun 11, 2021 4:31 pm
LdB wrote:
Fri Jun 11, 2021 3:19 pm
Even if the C standard board made the standard the manufacturers of the CPU's won't accept it and ultimately demand their compiler vendors ignore it. Remember the CPU vendor sells us programmers the compiler (one off cost or annual subscription) and ultimately they decide if the standard lives or dies (they already killed a few last year). Microsoft does the same they often ignore C/C++ standards they don't agree with.
I seriously doubt any CPU manufacturer or compiler vendor would ignore what has long been considered standard integer representation and operation.
One would think, but the weird way segments worked on 8086 and 8088 was different than any other computer, destroyed pointer arithmetic in C and subsequently put into the standard.

FidoBasic was chosen as the system programming language for the cactus-stack friendly BARK™ to avoid similar problems when using the modern three-tiered address space.

If Digital Research had been properly brought onboard when the IBM PC was released, the C programming language might have remained a Unix novelty and a language more suitable for use with segmented memory developed. That might also have avoided a number of other programming blunders that later turned into security problems.

jahboater
Posts: 7203
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

### Re: Schrödinger's Code - Undefined behavior in theory and practice

ejolson wrote:
Fri Jun 11, 2021 5:05 pm
FidoBasic was chosen as the system programming language for the cactus-stack friendly BARK™ to avoid similar problems when using the modern three-tiered address space.
Is the modern three-tiered NUMA space the reason for this possible UB (from the list of UB's in the C18 standard)??

Code: Select all

``````The result of subtracting two pointers is not representable in an object of type ptrdiff_t
(6.5.6).``````

jahboater
Posts: 7203
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

### Re: Schrödinger's Code - Undefined behavior in theory and practice

LdB wrote:
Fri Jun 11, 2021 3:19 pm
So remember everyone can have good ideas but at the end of the day if you aren't paying you don't get a say
We don't pay for GCC or Clang and they both adhere to the standards as far as possible. Anywhere the compiler differs from the standard is reason to raise a bug report - are they are dealt with. They even have experimental support for yet to be published draft standards.
LdB wrote:
Fri Jun 11, 2021 3:19 pm
Microsoft does the same they often ignore C/C++ standards they don't agree with.
That's why I no longer use MSVC.

Heater
Posts: 18373
Joined: Tue Jul 17, 2012 3:02 pm

### Re: Schrödinger's Code - Undefined behavior in theory and practice

LdB wrote:
Fri Jun 11, 2021 3:19 pm
x = y + z;
That is signed addition...
Is it? From reading that single statement one cannot make such an assumption.

Even if we look for the declarations we still might not know what size integer it is or what happens when it overflows. Being either undefined behaviour or implementation defined.
LdB wrote:
Fri Jun 11, 2021 3:19 pm
...and there are multiple things that can happen on different CPU's and DSP's if it rolls
Very true.

Problem is, when I write software I want it to do what I say, all the time, every time. No matter what hardware or compiler or operating system. If I were to give you my code to do something for you I'm sure you would be happier if it actually did that. Rather than you having to fix all the bugs caused by you having a different computer than me.
LdB wrote:
Fri Jun 11, 2021 3:19 pm
It will remain undefined in C as a common implementation on all CPU cores can't be done they don't have the traps in silicon to do it
Also true.

Problem is that disconnect between our software world and what hardware does is the source of endless bugs and security vulnerabilities.
LdB wrote:
Fri Jun 11, 2021 3:19 pm
Even if the C standard board made the standard the manufacturers of the CPU's won't accept it and ultimately demand their compiler vendors ignore it.
That is an interesting point.

Back in the day Motorola made a big sales pitch about how their new 6809 processors instruction set was optimised to run the kind of code programmers actually write, after analysing a lot of typical programs, which at the time were of course written in assembler.

Basically the 6809 instruction set was designed to support the assembler programmer.

If you look at Intel's x86 instruction set I'm sure you will see that it also is designed to support the assembler language programmer, with all it's baroque CISC instructions.

Problem there is programmers using high level languages, from C up wards, use compilers. Compilers tend not to use most of those assembler programmer instructions.

Enter the RISC architecture. There they designed the instruction set to optimise what compilers, like C compilers, actually can do.

Never mind all that RISC vs CISC stuff. The point I am trying to make is that there has been a symbiosis going on between programming language designers, compiler writers and processor architects for many decades now.

It never happened but if the Ada language had been adopted by the world's programmers all those years ago I'm sure processor hardware would have sprouted support for what Ada does. Like number overflow and so on.
LdB wrote:
Fri Jun 11, 2021 3:19 pm
Remember the CPU vendor sells us programmers the compiler (one off cost or annual subscription)
Now you have totally lost me. What on Earth are you talking about?

I have not used a compiler supplied by a processor vendor since the early 1980's. When we used the PL/M language compiler that Intel provided. At a cost of thousands of dollars.

Since then all language compilers used by almost everybody have not been supplied by the processor vendor. Even in the PC world the compiler comes from Microsoft or other, not Intel.

Even in the embedded system world we mostly see people using GCC or whatever. Not anything the hardware vendor created.
LdB wrote:
Fri Jun 11, 2021 3:19 pm
...and ultimately they decide if the standard lives or dies (they already killed a few last year).
Actually, I would really like you to tell what programming language standards hardware vendors have killed in the last year.
LdB wrote:
Fri Jun 11, 2021 3:19 pm
Microsoft does the same they often ignore C/C++ standards they don't agree with.
Historically this seems to be true. As far as I can tell MS is doing much better at supporting C/C++ standards. Even going as far as open sourcing their implementation of the standard template library and being active on the standards committee.
LdB wrote:
Fri Jun 11, 2021 3:19 pm
That is so easy to write in a defined way it's actually a none issue and I know a few who would ask why is this even getting airtime.
I think these things deserve air time because apparently many people, like yourself, have not thought it through very deeply and are content to just accept the way things are, because that is how they are.
LdB wrote:
Fri Jun 11, 2021 3:19 pm
So remember everyone can have good ideas but at the end of the day if you aren't paying you don't get a say
Perhaps true.

But what do you mean by "paying for it"?

Many people have a say in the C and especially C++ language standards evolution. They don't pay with hard cash. They pay with the work they put in to understand what is going on, write proposals, create implementations, argue their case, and so on, and so on.

Others get their say by rolling up their sleeves and creating new programming languages that work the way they like, be it D or Zig or Julia, or Rust or ...
Memory in C++ is a leaky abstraction .

Heater
Posts: 18373
Joined: Tue Jul 17, 2012 3:02 pm

### Re: Schrödinger's Code - Undefined behavior in theory and practice

Paeryn wrote:
Thu Jun 10, 2021 8:54 pm
The hardware has to return some value, it may be either a best answer should you not care about the exception (the NaN returned above is a quiet NaN in that it can usually propogate through a calculation without signaling more errors) or an indication as to why the exception happened.
Very true.

All those transistors in a CPU will be mashing on your request, be it divide by zero or whatever, and doing whatever they do. Not only that I'm sure every processor architecture does it in subtly different ways.

I see no reason why all of that mechanics should show up in the syntax and semantics of a high level programming language that we expect to do what we programmers write, no matter where it is run. Or when in the future.

In the same way that even C hides all the mechanics of the actual machine instructions the compiler generates or how it creates function calls, loops, etc, etc.
Memory in C++ is a leaky abstraction .

jahboater
Posts: 7203
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

### Re: Schrödinger's Code - Undefined behavior in theory and practice

Heater wrote:
Fri Jun 11, 2021 6:36 pm
Not only that I'm sure every processor architecture does it in subtly different ways.
I sincerely hope not.
(Nearly?) all modern FPU's conform to IEEE 754-2008 and must behave in exactly the same way. Bit for bit identical results.
[/quote]Its such a strong standard that I believe the C standard defers to IEEE 754 for the behavior of floating point, rather than duplicate everything.
Last edited by jahboater on Fri Jun 11, 2021 6:55 pm, edited 1 time in total.

Heater
Posts: 18373
Joined: Tue Jul 17, 2012 3:02 pm

### Re: Schrödinger's Code - Undefined behavior in theory and practice

ejolson wrote:
Fri Jun 11, 2021 5:05 pm
If Digital Research had been properly brought onboard when the IBM PC was released, the C programming language might have remained a Unix novelty and a language more suitable for use with segmented memory developed. That might also have avoided a number of other programming blunders that later turned into security problems.
That is an interesting observation.

I'm wondering what it is you think DR might have brought to the PC table?

Back in the day I worked on a CAD system for electronic schematic and PCB design. It all ran on an IBM compatible PC, MS-DOS, and was written in PL/M 86.

PL/M was created by the founder of DR, Gary Kildall. And he sold the idea to Intel in the 8 bit days. Even before CP/M.

PL/M 86 was Intel's reincarnation of PL/M for the 16 bit segmented memory architecture of the x86. Worked really well.

Amazingly, 30 or more years later you can still buy that CAD package. It was semi-auto translated to C last time I worked on it. No doubt further developed in C++ since then : https://www.zuken.com/en/resource/datas ... cb-layout/

Anyway, I see no reason a high level language "more suitable for use with segmented memory" ever needs to exist. It's a mess. It's unnecessary. It has put warts into the C standard, that are still there, that we don't need.
Memory in C++ is a leaky abstraction .

Heater
Posts: 18373
Joined: Tue Jul 17, 2012 3:02 pm

### Re: Schrödinger's Code - Undefined behavior in theory and practice

jahboater wrote:
Fri Jun 11, 2021 6:55 pm
I sincerely hope not.
(Nearly?) all modern FPU's conform to IEEE 754-2008 and must behave in exactly the same way. Bit for bit identical results.
[/quote]Its such a strong standard that I believe the C standard defers to IEEE 754 for the behavior of floating point, rather than duplicate everything.
[/quote]
You hope in vain.

The IEEE 754 standard is a wonderful thing.

However, there are observable differences in implementations across different architectures. Perhaps most notably being that Intel floating point units work to 80 bits precision for 64 bit floats.

Have a google search for "differences between float results arm intel" and see what chaos you find.
Memory in C++ is a leaky abstraction .

lurk101
Posts: 696
Joined: Mon Jan 27, 2020 2:35 pm
Location: Cumming, GA (US)

### Re: Schrödinger's Code - Undefined behavior in theory and practice

Heater wrote:
Fri Jun 11, 2021 6:19 pm
Since then all language compilers used by almost everybody have not been supplied by the processor vendor. Even in the embedded system world we mostly see people using GCC or whatever. Not anything the hardware vendor created.
In my experience most doing commercial embedded on ARM have used ARM's compiler. With 10-15% efficiency gains over GCC.
How to make your arguments stronger? Longer is not the answer.

Heater
Posts: 18373
Joined: Tue Jul 17, 2012 3:02 pm

### Re: Schrödinger's Code - Undefined behavior in theory and practice

lurk101 wrote:
Fri Jun 11, 2021 7:26 pm
Heater wrote:
Fri Jun 11, 2021 6:19 pm
Since then all language compilers used by almost everybody have not been supplied by the processor vendor. Even in the embedded system world we mostly see people using GCC or whatever. Not anything the hardware vendor created.
In my experience most doing commercial embedded on ARM have used ARM's compiler. With 10-15% efficiency gains over GCC.
I suggest that is pretty rare.

In my experience of doing commercial embedded work on ARM, going back nearly two decades, nobody has used ARM's compiler.

Now a days most imbedded ARM is in phones, set top boxes, domestic routers etc, etc. All built with GCC or Clang.
Memory in C++ is a leaky abstraction .

jahboater
Posts: 7203
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

### Re: Schrödinger's Code - Undefined behavior in theory and practice

The ARM compiler is just based on LLVM, like Clang, is it not?

lurk101
Posts: 696
Joined: Mon Jan 27, 2020 2:35 pm
Location: Cumming, GA (US)

### Re: Schrödinger's Code - Undefined behavior in theory and practice

jahboater wrote:
Fri Jun 11, 2021 9:30 pm
The ARM compiler is just based on LLVM, like Clang, is it not?
It is standard LLVM C/C++ front end with ARM proprietary machine code generation and optimization back end.

As far as I can tell it makes finer grain distinctions between ARM core variants, their strengths and weaknesses, than GCC or CLANG.
How to make your arguments stronger? Longer is not the answer.

LdB
Posts: 1703
Joined: Wed Dec 07, 2016 2:29 pm

### Re: Schrödinger's Code - Undefined behavior in theory and practice

Heater wrote:Even in the embedded system world we mostly see people using GCC or whatever. Not anything the hardware vendor created.
You are clearly not in the embedded market or you would not make that comment and further discussion is thus pointless.
Heater wrote:Actually, I would really like you to tell what programming language standards hardware vendors have killed in the last year.
VLA's got killed dead late 2020

They were mandatory in C99, optional in C11 because nobody supported them. To go further google paid for all VLA's to be removed from linux source code which had been added in the period.

Then MS took a stance in both C11 & C17 in 2020
https://devblogs.microsoft.com/cppblog/ ... g-in-msvc/
There reasoning is clear "VLAs provide attack vectors"

The Standards committee may put up junk but the embedded industry will simply refuse to go along.
If they push it too far the industry is likely to simply form it''s own standards committee a suggestion put to MS and Intel.
Heater wrote: I think these things deserve air time because apparently many people, like yourself, have not thought it through very deeply and are content to just accept the way things are, because that is how they are.
No we do it for a living and much of your sort of suggestions is just a waste of our time.
I pay over \$2000USD for my C compilers per year and so I pay for the compiler vendors to care what I think.
Heater wrote: But what do you mean by "paying for it"?
So how much per year do you pay to compiler developers?
Heater wrote: Others get their say by rolling up their sleeves and creating new programming languages that work the way they like, be it D or Zig or Julia, or Rust or ..
Of little interest to me, we have far to many qualified libraries to ever bother going down that path.

Anyhow I think we have wasted enough time on this .. you clearly have some goal so good luck with it all.

jahboater
Posts: 7203
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

### Re: Schrödinger's Code - Undefined behavior in theory and practice

Heater wrote:
Fri Jun 11, 2021 7:15 pm
You hope in vain.

The IEEE 754 standard is a wonderful thing.

However, there are observable differences in implementations across different architectures. Perhaps most notably being that Intel floating point units work to 80 bits precision for 64 bit floats.
No!
That's nothing to do with IEEE 754.
For legacy 32-bit Intel code, compilers may choose to use the available higher precision for intermediate calculations.
At (indeterminate) points, the value is stored back in 64-bit precision. Thus the results change slightly depending on the compiler or level of optimization. Its a compiler thing for legacy code, nothing to do with IEEE 754.

If you tell the compiler not to do that and stick with 64-bit arithmetic (-mfpmath=sse), then everything is done in 64-bits and all is well.
Never happens in 64-bit mode which doesn't use the slow old 80-bit stuff by default, its always 64-bits, IEEE binary64, only.

Other possibilities these days are the compiler doing "compile time arithmetic" using MPFR (arbitrary precision), or eliding the arithmetic altogether.
Again, nothing to do with IEEE 754. Different arithmetic with different precision.

If you do the same arithmetic, in the same order, with the same precision, you will get identical results on all fully IEEE 754 compliant hardware.
If you didn't, IEEE 754 might as well not exist.
Heater wrote:
Fri Jun 11, 2021 7:15 pm
Have a google search for "differences between float results arm intel" and see what chaos you find.
Read the results carefully. All the cases my search found were compiler or optimization differences.
Please show me a sequence of floating point instructions (in pseudo assembler) that returns differing results on different IEEE compliant hardware?

Its called ISO/IEC 60559 now.
https://www.iso.org/standard/80985.html

lurk101
Posts: 696
Joined: Mon Jan 27, 2020 2:35 pm
Location: Cumming, GA (US)

### Re: Schrödinger's Code - Undefined behavior in theory and practice

LdB wrote:
Sat Jun 12, 2021 3:22 am
Heater wrote:Even in the embedded system world we mostly see people using GCC or whatever. Not anything the hardware vendor created.
You are clearly not in the embedded market or you would not make that comment and further discussion is thus pointless.
Heater wrote:Actually, I would really like you to tell what programming language standards hardware vendors have killed in the last year.
VLA's got killed dead late 2020

They were mandatory in C99, optional in C11 because nobody supported them. To go further google paid for all VLA's to be removed from linux source code which had been added in the period.

Then MS took a stance in both C11 & C17 in 2020
https://devblogs.microsoft.com/cppblog/ ... g-in-msvc/
There reasoning is clear "VLAs provide attack vectors"

The Standards committee may put up junk but the embedded industry will simply refuse to go along.
If they push it too far the industry is likely to simply form it''s own standards committee a suggestion put to MS and Intel.
Heater wrote: I think these things deserve air time because apparently many people, like yourself, have not thought it through very deeply and are content to just accept the way things are, because that is how they are.
No we do it for a living and much of your sort of suggestions is just a waste of our time.
I pay over \$2000USD for my C compilers per year and so I pay for the compiler vendors to care what I think.
Heater wrote: But what do you mean by "paying for it"?
So how much per year do you pay to compiler developers?
Heater wrote: Others get their say by rolling up their sleeves and creating new programming languages that work the way they like, be it D or Zig or Julia, or Rust or ..
Of little interest to me, we have far to many qualified libraries to ever bother going down that path.

Anyhow I think we have wasted enough time on this .. you clearly have some goal so good luck with it all.
Without the accusation would be well put and to the point. Pragmatism trumps ideology.
How to make your arguments stronger? Longer is not the answer.

ejolson
Posts: 7619
Joined: Tue Mar 18, 2014 11:47 am

### Re: Schrödinger's Code - Undefined behavior in theory and practice

lurk101 wrote:
Sat Jun 12, 2021 1:28 pm
LdB wrote:
Sat Jun 12, 2021 3:22 am
Heater wrote:Even in the embedded system world we mostly see people using GCC or whatever. Not anything the hardware vendor created.
You are clearly not in the embedded market or you would not make that comment and further discussion is thus pointless.
Heater wrote:Actually, I would really like you to tell what programming language standards hardware vendors have killed in the last year.
VLA's got killed dead late 2020

They were mandatory in C99, optional in C11 because nobody supported them. To go further google paid for all VLA's to be removed from linux source code which had been added in the period.

Then MS took a stance in both C11 & C17 in 2020
https://devblogs.microsoft.com/cppblog/ ... g-in-msvc/
There reasoning is clear "VLAs provide attack vectors"

The Standards committee may put up junk but the embedded industry will simply refuse to go along.
If they push it too far the industry is likely to simply form it''s own standards committee a suggestion put to MS and Intel.
Heater wrote: I think these things deserve air time because apparently many people, like yourself, have not thought it through very deeply and are content to just accept the way things are, because that is how they are.
No we do it for a living and much of your sort of suggestions is just a waste of our time.
I pay over \$2000USD for my C compilers per year and so I pay for the compiler vendors to care what I think.
Heater wrote: But what do you mean by "paying for it"?
So how much per year do you pay to compiler developers?
Heater wrote: Others get their say by rolling up their sleeves and creating new programming languages that work the way they like, be it D or Zig or Julia, or Rust or ..
Of little interest to me, we have far to many qualified libraries to ever bother going down that path.

Anyhow I think we have wasted enough time on this .. you clearly have some goal so good luck with it all.
Without the accusation would be well put and to the point. Pragmatism trumps ideology.
From a pragmatic point of view US\$ 2000 may seem like enough money someone would care. In reality that's so small that big companies who make their profits on other things, such as Intel or ARM could drop the entire compiler in the blink of an eye. In a way, this is what Intel did with CilkPlus. The same trend is further reflected by the previously stated goal of contributing all meaningful optimisation techniques used in icc to open source.

My observation is that git and other code sharing tools have provided open source such useful quality assurance and maintenance opportunities that closed source is noticeably less profitable in many cases both for the company making the software as well as the ones buying it.

Although modern innovations in software and computing technology center around the cloud and data center, embedded is an important area where changes to old ways of doing things may be necessary, not only to remain competitive, but due to the announcement of unannounced cyber retaliations development practices with auditably secure and maintainable supply chains are needed to avoid being an outright liability.

lurk101
Posts: 696
Joined: Mon Jan 27, 2020 2:35 pm
Location: Cumming, GA (US)

### Re: Schrödinger's Code - Undefined behavior in theory and practice

ejolson wrote:
Sun Jun 13, 2021 3:31 pm
From a pragmatic point of view US\$ 2000 may seem like enough money someone would care. In reality that's so small that big companies who make their profits on other things, such as Intel or ARM could drop the entire compiler in the blink of an eye. In a way, this is what Intel did with CilkPlus. The same trend is further reflected by the previously stated goal of contributing all meaningful optimisation techniques used in icc to open source.
Always possible ARM might do so at some point. ARM's compiler revenue is negligible, in fact it's often bundled with core licensing. It does indirectly add much value to their core designs. 10-15% performance gain is significant in embedded.
My observation is that git and other code sharing tools have provided open source such useful quality assurance and maintenance opportunities that closed source is noticeably less profitable in many cases both for the company making the software as well as the ones buying it.
That open source is somehow inherently more secure or has better quality is contested.

CVE-2021-3560 - been around for 7 years in all systemd ditros. Easily exploited.
Although modern innovations in software and computing technology center around the cloud and data center, embedded is an important area where changes to old ways of doing things may be necessary, not only to remain competitive, but due to the announcement of unannounced cyber retaliations development practices with auditably secure and maintainable supply chains are needed to avoid being an outright liability.
Heightened cyber security awareness is certainly the latest trend. Practically though I don't see how C/C++ could fail to dominate embedded for the foreseeable future.
How to make your arguments stronger? Longer is not the answer.

Heater
Posts: 18373
Joined: Tue Jul 17, 2012 3:02 pm

### Re: Schrödinger's Code - Undefined behavior in theory and practice

LdB wrote:
Sat Jun 12, 2021 3:22 am
You are clearly not in the embedded market or you would not make that comment and further discussion is thus pointless.
That is an unfounded assumption. I have worked on embedded systems, on and off, since 1980. Within all kind of companies and industries. From traffic light controllers to Rolls Royce jet engine controllers to Boeing 777 Primary Flight Computers to Nokia networks. And plenty of others inbetween. Still am today.

My claim was that no project I have ever worked on during that time used a compiler from the vendor of the CPU in use. At least not since we used Intel's PL/M compiler in the early days.

That is why I made that comment. Because it's a true fact of my long experience. You may well have a different experience.

LdB wrote:
Sat Jun 12, 2021 3:22 am
VLA's got killed dead late 2020

They were mandatory in C99, optional in C11 because nobody supported them. To go further google paid for all VLA's to be removed from linux source code which had been added in the period.

Then MS took a stance in both C11 & C17 in 2020
https://devblogs.microsoft.com/cppblog/ ... g-in-msvc/
There reasoning is clear "VLAs provide attack vectors"

The Standards committee may put up junk but the embedded industry will simply refuse to go along.
If they push it too far the industry is likely to simply form it''s own standards committee a suggestion put to MS and Intel.
VLA's are an interesting case.

VLA's turned out be a really bad idea that the standards guys have done there best to expunge.

I don't know so it would be interesting to know the history of VLA's. Who's idea was it? Where did it come from? Why did anyone think it was a good idea?

I find your whole argument there confusing. I mean MS is not a vendor of processors or even compilers for embedded processors. Intel is not a vendor of processors for embedded systems.
LdB wrote:
Sat Jun 12, 2021 3:22 am
No we do it for a living and much of your sort of suggestions is just a waste of our time.
I pay over \$2000USD for my C compilers per year and so I pay for the compiler vendors to care what I think.
This is gibberish.

As stated above I do this for a living as well.

Are you telling me that your \$2000 per year gets you a hot seat on the C standards committee? That whatever ideas you have about the C language might get standardised? I very much doubt it.

If it means your compiler vendor fixes bugs and sorts out your issues in a timely manner then OK, well and good, why not.
LdB wrote:
Sat Jun 12, 2021 3:22 am
So how much per year do you pay to compiler developers?
Nothing of course. Like most people.

Except perhaps in the effort expended in making comprehensive bug reports when bugs are found. Creating test cases, etc. Not much but something.
LdB wrote:
Sat Jun 12, 2021 3:22 am
Of little interest to me, we have far to many qualified libraries to ever bother going down that path.
Very good. Nobody is suggesting you throw all that away. That would be silly.
LdB wrote:
Sat Jun 12, 2021 3:22 am
Anyhow I think we have wasted enough time on this .. you clearly have some goal so good luck with it all.
Yep, I do indeed have a goal with this. Perhaps not what you think it is.

If you find a discussion about the creation of correct, robust software a waste of time then perhaps you should not be wasting your time reading this or even be working on creating software at all.
Memory in C++ is a leaky abstraction .

Heater
Posts: 18373
Joined: Tue Jul 17, 2012 3:02 pm

### Re: Schrödinger's Code - Undefined behavior in theory and practice

jahboater wrote:
Sat Jun 12, 2021 9:44 am
No!
That's nothing to do with IEEE 754.
Well... I'm inclined to agree with you. As I said IEEE 754 is a wonderful thing.

However in the world of C and C++ there is a lot of chaos. So much so that NASA has a page dedicated to it:

"Consistency of Floating Point Results or Why doesn’t my application always give the same answer?" https://www.nccs.nasa.gov/images/Floati ... stency.pdf

And many other examples around the net.

As you say, this chaos can be tamed somewhat with compiler options. But that is all outside the language standard is it not?
Memory in C++ is a leaky abstraction .

Return to “C/C++”