A superb talk. I wish I could have attended. It must be hard work if presenting to a lack-lustre, unresponsive audience. Robert made so many excellent points. Thanks!
The audience was good. Lot's of familiar faces there. You can't hear them in the recording because of production choices. But definitely join us next time!
Great talk Robert!! There’s a lot of wisdom and insight to learn from someone who’s been doing this for 20 years and is looking to solve underlying challenges.
12:10 This might be UB even without overflow. The result of adding an integer to a pointer must point to an element from the same array or at most one element past it. And if it's, let's say, two elements past the end of the array, it's UB already even without overflow.
Why it's UB? I mean, it's just an evaluation of an expression. in that particular example, there is no de-reference or any kind of change of the state. The only UB can occurs is overflow.
The community mentality resonated a lot with my experience with coworkers, I don't blame them that's how they were taught. But this talk is surely something I can show them.
I sympathise with the conclusion of this talk. I think C is just fine, it's a small, simple, performant language that has fulfilled its reason for being very well, that being enabling Unix to escape from assembler into a portable language. C can continue to fill such roles. C should stay simple, such that, say, one man can write a C compiler in a reasonable time frame. I'm sure there are some aspects of undefined behaviours that can be tightened up a bit though. Meanwhile C++ is an out of control, giant monster forever gaining more ugly and unwieldy warts (features). There is no hope of ever making it a "safe" language in which to write robust , reliable, software. As language at a much higher level than C we have many better alternatives today.
@@doBobro I know what you mean. Although C is still a simple enough language that one man can write a compiler for it in a reasonable time. All those UB's are annoying but my recollection that they always were. Maybe many people did not notice but I often had to move C code from architecture to architecture, compiler to compiler, and all kind of surprises would crop up in the process. All because of this UB's and implementation defined features. Still, now we have Rust and life is much better. If it compiles it almost certainly runs and quite often correctly first time. There is no going back to C or C++ for me. I regard use of those in safety critical, high reliability and/or secure systems as professional negligence now that far better alternatives, like Rust, exist.
@@doBobro If UB is causing you problems then you are not writing C as per the specification. Likely you never have been but compilers had less sophisticated optimisers and you got away with it. Back in the day typically such UB. problems did not show up until you tried using the code. on some different architectures. At which point one found out that compilers and architectures can do different thing when writing UB.
@@Heater-v1.0.0 "not writing C as per the specification" is a quite bad argument. There is no single person in the world able to not make a mistake starting from Nth line of C code. It's a common sense that compilers should check my code adheres to spec but not in C case. As you said UB time bomb is a real scary thing.
@@doBobro I don't think I was making the argument you think I was. I agree, blaming failures in C/C++ code on the lack of care or skill of the programmer is a bad argument. I agree that all programmers, whatever skill they have and care they take, will make mistakes. I was simply pointing out that we have been making all those mistakes since forever. Something I have often observed since I started coding in C in 1980, especially when moving projects from one compiler to another or one architecture to another. I was claiming that blaming modern compilers and their optimisers for ones mistakes, which did not show up before quite by chance, is not sensible. Yes, I agree that if we can have compilers that can catch as many of those silly errors as possible we should use them. Which is why I only used Rust for the past 5 years. In fact I will claim that it is professional negligence to not use such tools. Meanwhile, I think C can stay as it is. It's about the smallest simplest way we can have a portable high-level language. Trying to bend it into something safe like Rust is impossible. Perhaps we can use the awesome powers of AI and LLMs to point out potential mistakes in C code, who knows. C++ has become so huge and complex, whilst failing to fix any of the problems with C that it's best avoided.
So what happened? Back in the 1980s/90s we had the Ada langauge for those that wanted to created robust, reliable software. Then everyone decided to drop it in favour of the extremely error prone C and C++. I think it would be very good to get back to those expectations of quality that we had in the Ada days and the ALGOL days before that. To that end we have the likes of Rust tackling the problem.
Is this pointer + size integer overflow actually relevant on any OS today with 64 bit esp. when the processor only uses 48 Bit of the address? Was it even relevant on 32 Bit OS's? And then still a overflow into the "good" area could happen giving potentially a logic error. Do buffer overflows still have a relevant impact in current software quality? Isn't the obsession with ultimate "safety" on a isolated aspect leading to the ignorance of the whole picture and other, more pragmatic safety issues?
IMHO conclusion is too optimistic. C could become obscure legacy language quite fast like COBOL because nobody wants to program in it. There are a plenty of more DX friendly options now.
A superb talk. I wish I could have attended. It must be hard work if presenting to a lack-lustre, unresponsive audience. Robert made so many excellent points. Thanks!
The audience was good. Lot's of familiar faces there. You can't hear them in the recording because of production choices. But definitely join us next time!
@@RobertSeacordC My mistake, for which I apologise. I'm relieved!
Great talk Robert!! There’s a lot of wisdom and insight to learn from someone who’s been doing this for 20 years and is looking to solve underlying challenges.
12:10 This might be UB even without overflow. The result of adding an integer to a pointer must point to an element from the same array or at most one element past it. And if it's, let's say, two elements past the end of the array, it's UB already even without overflow.
yes it is UB without overflow, but the overflow part makes it pretty easy for the compiler to detect it.
Why it's UB? I mean, it's just an evaluation of an expression. in that particular example, there is no de-reference or any kind of change of the state. The only UB can occurs is overflow.
@@afnman83 by standard you can have pointer to last array element + 1 only.
The community mentality resonated a lot with my experience with coworkers, I don't blame them that's how they were taught. But this talk is surely something I can show them.
I sympathise with the conclusion of this talk. I think C is just fine, it's a small, simple, performant language that has fulfilled its reason for being very well, that being enabling Unix to escape from assembler into a portable language. C can continue to fill such roles. C should stay simple, such that, say, one man can write a C compiler in a reasonable time frame. I'm sure there are some aspects of undefined behaviours that can be tightened up a bit though.
Meanwhile C++ is an out of control, giant monster forever gaining more ugly and unwieldy warts (features). There is no hope of ever making it a "safe" language in which to write robust , reliable, software. As language at a much higher level than C we have many better alternatives today.
C was simple a long time ago. UB handling in modern compilers makes it simply unbearable.
@@doBobro I know what you mean. Although C is still a simple enough language that one man can write a compiler for it in a reasonable time. All those UB's are annoying but my recollection that they always were. Maybe many people did not notice but I often had to move C code from architecture to architecture, compiler to compiler, and all kind of surprises would crop up in the process. All because of this UB's and implementation defined features.
Still, now we have Rust and life is much better. If it compiles it almost certainly runs and quite often correctly first time. There is no going back to C or C++ for me. I regard use of those in safety critical, high reliability and/or secure systems as professional negligence now that far better alternatives, like Rust, exist.
@@doBobro If UB is causing you problems then you are not writing C as per the specification. Likely you never have been but compilers had less sophisticated optimisers and you got away with it. Back in the day typically such UB. problems did not show up until you tried using the code. on some different architectures. At which point one found out that compilers and architectures can do different thing when writing UB.
@@Heater-v1.0.0 "not writing C as per the specification" is a quite bad argument. There is no single person in the world able to not make a mistake starting from Nth line of C code. It's a common sense that compilers should check my code adheres to spec but not in C case. As you said UB time bomb is a real scary thing.
@@doBobro I don't think I was making the argument you think I was. I agree, blaming failures in C/C++ code on the lack of care or skill of the programmer is a bad argument. I agree that all programmers, whatever skill they have and care they take, will make mistakes. I was simply pointing out that we have been making all those mistakes since forever. Something I have often observed since I started coding in C in 1980, especially when moving projects from one compiler to another or one architecture to another. I was claiming that blaming modern compilers and their optimisers for ones mistakes, which did not show up before quite by chance, is not sensible.
Yes, I agree that if we can have compilers that can catch as many of those silly errors as possible we should use them. Which is why I only used Rust for the past 5 years. In fact I will claim that it is professional negligence to not use such tools.
Meanwhile, I think C can stay as it is. It's about the smallest simplest way we can have a portable high-level language. Trying to bend it into something safe like Rust is impossible. Perhaps we can use the awesome powers of AI and LLMs to point out potential mistakes in C code, who knows. C++ has become so huge and complex, whilst failing to fix any of the problems with C that it's best avoided.
So what happened? Back in the 1980s/90s we had the Ada langauge for those that wanted to created robust, reliable software. Then everyone decided to drop it in favour of the extremely error prone C and C++. I think it would be very good to get back to those expectations of quality that we had in the Ada days and the ALGOL days before that. To that end we have the likes of Rust tackling the problem.
31:40 :)
Is this pointer + size integer overflow actually relevant on any OS today with 64 bit esp. when the processor only uses 48 Bit of the address? Was it even relevant on 32 Bit OS's? And then still a overflow into the "good" area could happen giving potentially a logic error.
Do buffer overflows still have a relevant impact in current software quality?
Isn't the obsession with ultimate "safety" on a isolated aspect leading to the ignorance of the whole picture and other, more pragmatic safety issues?
Awesome talk! Thanks for sharing, always enjoy hearing Robert talk. Hope to meet IRL someday.
Come this year! I'll be back.
IMHO conclusion is too optimistic. C could become obscure legacy language quite fast like COBOL because nobody wants to program in it. There are a plenty of more DX friendly options now.
If only C had +% operator