Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"No way to prevent this" say users of only language where this regularly happens

xeiaso.net

Post reply on HN
Print view View original

161–170 of 342 posts

Re: "No way to prevent this" say users of only language where this regularly happens

#161

Post by aw1621107 »

pjc50 wrote: post #109
pdimitar wrote: post #88

Earlier quoted context omitted.

C/C++ being non-opinionated is the main source of the security vulnerabilities. Let's face it, it felt good to be a lone cowboy carrying a lot of responsibility and knowing what you are doing. I was there myself and I'll admit the ego trip was awesome. These times are long past and naturally, people refuse to adapt. > Unfortunately you can't just have Rust's safety checks, without opting into restrictions that Rust d…

> C/C++ being non-opinionated is the main source of the security vulnerabilities This. "Undefined behavior" is such a terrible way of thinking. As is the "we can assume in the optimizer that UB does not happen and then eliminate code on that basis", which allows the compiler to introduce bugs that only appear at certain -O levels. It took decades to get them to define arithmetic as twos-complement.

> It took decades to get them to define arithmetic as twos-complement.

I'm not sure this is right? IIRC C++20/C23 require two's complement representation for signed integers but generally leave other behaviors (including signed overflow) the same.

[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p09...

Re: "No way to prevent this" say users of only language where this regularly happens

#162

Post by p_l »

lpribis wrote: post #139
p_l wrote: post #65

Earlier quoted context omitted.

Especially when one adds how many "low level programming" idioms for C are, as far as I understand, undefined behaviour in C. Like assigning an address to then use as pointer to physical memory... Which is extra visible when one looks at original UNIX sources and its many short assembly bits in separate files to handle bits of direct hw manipulation.

> Like assigning an address to then use as pointer to physical memory... What do you mean by this? Like writing to a specific integer address? *((volatile unsigned *)(0x20001000)) = 0x12345678; That's not UB and is also the only way to write to memmapped registers.

It's not UB. It's also not covered by standard - it's implementation-specified. What will happen is dependant on decision of compiler writers.

It is, however, not the only way to write to memmapped registers.

The original C way of doing so was to use an assembly function wrapping the actual act of reading/writing (honestly, better than doing the above, as it helps making it very explicit how the write will happen as well as abstracting any details like needing to add a barrier or whatsoever), the other way was to specify the symbol with address of the memmapped register in assembly, and link resulting object with C code.

A C implementation is, AFAIK, free to refuse the literal addresses used as pointers and pass as ISO C.

Re: "No way to prevent this" say users of only language where this regularly happens

#163

Post by amarant »

pdimitar wrote: post #149
anon-3988 wrote: post #146

Earlier quoted context omitted.

No, more people should be using memory managed languages like Java and Golang. Then educate and expose people to sum types and pattern matching. It is actually insane how people is still unconvinced about sum types. Imagine how insane it is to program without product types? That's exactly what it felt like.

> It is actually insane how people is still unconvinced about sum types. Oh don't even get me started on this but I agree sooooo much. > No, more people should be using memory managed languages like Java and Golang. Well, I use both Golang and Rust depending on the need. We can have both, it's not an either-or.

I'm feeling my lack of academic training here, but I needed to make sure. When you say sum types, are you referring to enums, or is it a broader concept than that? The Wikipedia article was quite archaic but seemed to support my initial understanding that you're talking about enums.

Are you talking about enums?

Re: "No way to prevent this" say users of only language where this regularly happens

#164

Post by pdimitar »

GoblinSlayer wrote: post #159
pdimitar wrote: post #53

I've been doing programming for ~31 years in total and ~22 years professionally and at this point I have lost all hope that programmers at large will ever gain these mythic qualities called "self-reflection" and "introspection". Truth is, these people are simply afraid for their cozy jobs, that's all there is to it. Derivative states of mind like Stockholm Syndrome and Sunk Cost Fallacy are quite normal to appear in…

It's possible to write systematically safe code in C, no need to change language. People really just don't want to do it.

Maybe it is but the last several years of periodic (and quite embarrassing) CVEs suggest otherwise.

Re: "No way to prevent this" say users of only language where this regularly happens

#165

Post by pdimitar »

amarant wrote: post #163
pdimitar wrote: post #149

Earlier quoted context omitted.

> It is actually insane how people is still unconvinced about sum types. Oh don't even get me started on this but I agree sooooo much. > No, more people should be using memory managed languages like Java and Golang. Well, I use both Golang and Rust depending on the need. We can have both, it's not an either-or.

I'm feeling my lack of academic training here, but I needed to make sure. When you say sum types, are you referring to enums, or is it a broader concept than that? The Wikipedia article was quite archaic but seemed to support my initial understanding that you're talking about enums. Are you talking about enums?

Yes, I am talking Rust enums and OCaml's enumerated data types.

Re: "No way to prevent this" say users of only language where this regularly happens

#166

Post by bell-cot »

GoblinSlayer wrote: post #159
pdimitar wrote: post #53

I've been doing programming for ~31 years in total and ~22 years professionally and at this point I have lost all hope that programmers at large will ever gain these mythic qualities called "self-reflection" and "introspection". Truth is, these people are simply afraid for their cozy jobs, that's all there is to it. Derivative states of mind like Stockholm Syndrome and Sunk Cost Fallacy are quite normal to appear in…

It's possible to write systematically safe code in C, no need to change language. People really just don't want to do it.

THIS, sadly. Though it'd be more accurate to re-phrase: 's/just don't want to do it/have other priorities, or are stuck in organizations with other priorities/'

Re: "No way to prevent this" say users of only language where this regularly happens

#167

Post by pjmlp »

jokteur wrote: post #112
pdimitar wrote: post #53

I've been doing programming for ~31 years in total and ~22 years professionally and at this point I have lost all hope that programmers at large will ever gain these mythic qualities called "self-reflection" and "introspection". Truth is, these people are simply afraid for their cozy jobs, that's all there is to it. Derivative states of mind like Stockholm Syndrome and Sunk Cost Fallacy are quite normal to appear in…

I would love to be able to use Rust in my professional project. Unfortunately, I am doing high performance scientific computing. Rust doesn't even come close to offer any good alternative to cross-plateform, cross-device (CPU/GPU) libraries such as OpenMP Target, Kokkos, SYCL, ... I believe we need Nvidia/AMD to take Rust seriously (I'm not sure it is even possible without unsafe everywhere) to be able to offer good…

At least C++ provides the tools to avoid this kind of problems, if one choses to do so, instead of insisting into C idioms.

Re: "No way to prevent this" say users of only language where this regularly happens

#168

Post by pdimitar »

bell-cot wrote: post #166
GoblinSlayer wrote: post #159

Earlier quoted context omitted.

It's possible to write systematically safe code in C, no need to change language. People really just don't want to do it.

THIS, sadly. Though it'd be more accurate to re-phrase: 's/just don't want to do it/have other priorities, or are stuck in organizations with other priorities/'

I get that we can't always do what we want in our jobs (and in some places quite rarely even). I get it fully and I sympathize.

But that still doesn't do C/C++ any favors. None of my Rust contracting work ever resulted in a buffer overflow.

Re: "No way to prevent this" say users of only language where this regularly happens

#169

Post by pjmlp »

GoblinSlayer wrote: post #159
pdimitar wrote: post #53

I've been doing programming for ~31 years in total and ~22 years professionally and at this point I have lost all hope that programmers at large will ever gain these mythic qualities called "self-reflection" and "introspection". Truth is, these people are simply afraid for their cozy jobs, that's all there is to it. Derivative states of mind like Stockholm Syndrome and Sunk Cost Fallacy are quite normal to appear in…

It's possible to write systematically safe code in C, no need to change language. People really just don't want to do it.

In theory, in 50 years of practice, not really.

Re: "No way to prevent this" say users of only language where this regularly happens

#170

Post by self_awareness »

flohofwoe wrote: post #153
self_awareness wrote: post #83

Earlier quoted context omitted.

Most programmers don't have any opinions, so if they use an unopinionated language, they end up using patterns that opinionated people use. So it's better to have one source of truth for opinions, so that we don't end up using the "wrong" opinions of people who talk more than they think.

Compiler/language people are also just "opinionated people" though. Some have good opinions, some have bad opinions. In the worst case you have opinions which are the result of a 'design by committee/community' process.

Single source of truth of opinions can be challenged and changed if one's arguments are good enough. The benefit is that it's easier to see the advantages and disadvantages for those opinions, because they're all in the same place.

This is in contrast to C++, where one organization creates a set of guidelines, another organization creates another set of guidelines. Valid arguments of critique in one organization are not seen in the other.

Single source of truth is also beneficial to compiler authors as well, because they get more feedback how the language is used and why.

Post reply on HN