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

181–190 of 342 posts

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

#181

Post by foldr »

pjc50 wrote: post #147
lpribis wrote: post #139

Earlier quoted context omitted.

> 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.

> That's not UB Please cite chapter and verse of the C standard which defines this behavior. Any edition.

I don't know if this particular example is UB or not, but the dichotomy here between 'defined' and 'not defined' is a false one, as C also specifies some constructs as having 'implementation defined' behavior. The behavior of such constructs is not defined in the standard, but is also not 'undefined' in the special sense of 'undefined behavior'.

Edit: Looks like the result in this case is implementation defined: https://stackoverflow.com/a/24212940

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

#182

Post by nailer »

Supermancho wrote: post #158
fnordian_slip wrote: post #6

Just in case someone needs the reference, the onion uses '"no way to prevent this" says only nation where this regularly happens' as a reoccurring article at every major school shooting[0], to highlight the frequency of such events and the fact that nothing has really changed since the last one. [0] https://www.theonion.com/no-way-to-prevent-this-says-only-na...

The oversimplification is part of the joke.

[flagged]

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

#183

Post by WesolyKubeczek »

Xeamek wrote: post #73
WesolyKubeczek wrote: post #62

Earlier quoted context omitted.

[flagged]

That's not how society progress. At some point you just disallow horses to go onto the high-speed road, and aren't waiting for literally every last farmer to sell their horse over a car.

High-speed roads are a low percentage of all roads.

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

#184

Post by flohofwoe »

pdimitar wrote: post #176
flohofwoe wrote: post #118

Earlier quoted context omitted.

IMHO it does and its not restricted to dynamic languages (like JS or Python), look at this Zig function signature for instance (just an example from my current dabbling): fn setData(comptime pins: anytype, bus: anytype, data: u8) @TypeOf(bus) In practice this looks and feels like dynamic typing, yet when looking at the compiler output it still resolves to optimal code (since it's "compile-time dynamic typing" not "ru…

Well you can make OCaml and Rust look like dynamic typing as well by omitting type signatures and squeezing the type inference engine as much as you can but I was under the impression that you have more asked about something that is very relaxed in terms of upfront requirements and be able to tighten it up later? That's why I claimed that no such language exists.

I was thinking more in terms of "language surface" but it didn't come across, C and Zig have a fairly small language surface (Zig a bit bigger than C), simple language primitives that can be combined quite freely and without much restrictions, but at the same time not carrying a lot of semantics the compiler could use to ensure safety (ignoring the "sloppiness" design warts of C though, like implicit type conversions, allowing accidential uninitialized data, or inverted defaults (mutable vs immutable) - these things are obvious problems but cannot be easily fixed in C or C++ because of backward compatibility requirements - they have been fixed in Zig though).

Rust is quite the opposite, more primitives that carry semantics (most of those in the stdlib though), a stronger but also more rigid type system, but those are pretty much needed for the compiler to guarantee safety.

The million dollar question is of course, can there be a more relaxed Rust with the same safety and performance guarantees, maybe by "squeezing the type inference engine" even more (and letting Rust look or somehow extract information across crate boundaries)? And do Rust programmers even see this as desirable, or are they mostly comfortable in their current sweet spot of the triangle?

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

#186

Post by WesolyKubeczek »

pjc50 wrote: post #68
WesolyKubeczek wrote: post #62

Earlier quoted context omitted.

[flagged]

Fine, but there's no reason you should be allowed to ship C in devices which have safety critical consequences to the public, including unnecessary risk of data security breaches through allowing buffer overruns. You can write in a nice safe sandbox over there. (maybe this will eventually be part of the UL/CE requirements, "contains no C code")

C and C++ have another brand of safety "safe" languages du jour don't have: it's an ISO standard. Granted, it's not a very good standard, but the upside is that everyone and their dog has a C compiler for every new architecture, and I bet C++ too. You are not, strictly speaking, beholden to any single compiler implementation out there, they all have their idiosyncrasies, but C won't disappear overnight.

It's more even than having a single foundation oversee it. C and C++ are largely immune to, say, a foundation dissolving because one day it turns out its members cannot comport themselves as responsible adults and a big enough drama ensues. The fact that C and C++ have no singular "community" to speak of is a very strong side.

So when there are at least two (or better three) fully independent implementations of your C alternative, we'll talk about gatekeeping C.

Now, if you are a vendor and capital owner, nothing forbids you from forbidding C within your company and devices you produce. That has been your prerogative since forever, predicated on your ability to afford it. I'm more wound up about activists and evangelists trying to impose their hobby horse upon others. You do you. Show, don't tell.

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

#187

Post by flohofwoe »

SpaceNugget wrote: post #178
flohofwoe wrote: post #118

Earlier quoted context omitted.

IMHO it does and its not restricted to dynamic languages (like JS or Python), look at this Zig function signature for instance (just an example from my current dabbling): fn setData(comptime pins: anytype, bus: anytype, data: u8) @TypeOf(bus) In practice this looks and feels like dynamic typing, yet when looking at the compiler output it still resolves to optimal code (since it's "compile-time dynamic typing" not "ru…

I'm not super familiar with Zig, but that appears to be the same as the rust function signature fn setData (pins: P, bus: B, data: u8) -> B; in rust, the P and B are resolved at compile time, not at runtime. If you wanted dynamic dispatch the types would be Box

Yes, it's essentially the same, the comptime attribute on the pins arg is quite important though (in the function body that's not shown).

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

#188

Post by MrBuddyCasino »

yau8edq12i wrote: post #74
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 program MCUs as a hobby. I wish I could use something better than C. Even C++ with RAII would be better. But somehow, even C++ support is spotty, with unsupported features, broken debugging, etc. for seemingly no reason. And all device-specific libraries are written in C, so I'd have to write C++ wrappers for every little thing. Send help...

Rust only works for a few popular targets, but if it is just a hobby then Zig might be an option. C interop is pretty seamless, so you don't face the problem of having to reinvent the universe.

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

#189

Post by williamcotton »

pdimitar wrote: post #165
amarant wrote: post #163

Earlier quoted context omitted.

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.

Or what F# calls a Discriminated Union.

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

#190

Post by nottorp »

pdimitar wrote: post #127
nottorp wrote: post #120

Earlier quoted context omitted.

Before the current "AI" hysteria, HN was full of "I've rewritten this thing that was working just fine in Rust". No mention of how it's better, has more features - or even has all the original's features - or anything about why you should use the rewrite instead of the original. Am I supposed to use a tool just because of what it's made of, or because it solves a problem for me?

> No mention of how it's better No embarrassing buffer overflow CVEs is a very good start. To me that's an actual selling point and I've migrated from almost all UNIX coreutils to Rust alternatives for that reason alone. > Am I supposed to use a tool just because of what it's made of, or because it solves a problem for me? No, as an adult you are supposed to not frame the discussion unfairly and ask the right questio…

The right questions according to who?

Are your coreutils replacements 100% drop-in?

Post reply on HN