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.
@964tractorboy8 ай бұрын
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!
@RobertSeacordC8 ай бұрын
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!
@964tractorboy6 ай бұрын
@@RobertSeacordC My mistake, for which I apologise. I'm relieved!
@tiagocerqueira94593 ай бұрын
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.
@Heater-v1.0.08 ай бұрын
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.
@doBobro7 ай бұрын
C was simple a long time ago. UB handling in modern compilers makes it simply unbearable.
@Heater-v1.0.07 ай бұрын
@@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.
@bmazi8 ай бұрын
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.
@RobertSeacordC8 ай бұрын
yes it is UB without overflow, but the overflow part makes it pretty easy for the compiler to detect it.
@afnman838 ай бұрын
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.
@doBobro7 ай бұрын
@@afnman83 by standard you can have pointer to last array element + 1 only.
@Heater-v1.0.08 ай бұрын
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.
@doBobro7 ай бұрын
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.
@deadbeefmonster8 ай бұрын
Awesome talk! Thanks for sharing, always enjoy hearing Robert talk. Hope to meet IRL someday.
@RobertSeacordC4 ай бұрын
Come this year! I'll be back.
@raymundhofmann766124 күн бұрын
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?