dbaupp

24 ms·

271.
by dbaupp 8y ago
This is not safe in general, even within a single language. For instance, on Windows, it is essentially required that a pointer is freed by code from the dynamic library (even if they're both written in, say, C) that allocated it, beca
272.
by dbaupp 8y ago
That removes the Sync requirement, but still requires Send, so doesn't completely resolve the requirement for thread-safety (e.g. Rc can't be stored).
273.
by dbaupp 8y ago
wasm's true goal is to bring more performance and technology-independence to the web, which leads to more decentralization, user power, etc. For instance, more things can "run everywhere" because the performance is acceptable
274.
by dbaupp 8y ago
Is minified JS fundamentally different? JS is already used as a write-only compilation target, and wasm doesn't seem worse than that (if you're concerned about its binary nature, there's a standard textual format). There&#x27
275.
by dbaupp 8y ago
How exactly does the model specify which loads/stores are okay to be ignored or reordered (etc.)? I feel like anything that gets close to the essence of the C/C++/Rust model (such as allowing the optimization in my example ab
276.
by dbaupp 8y ago
p could be int *p = rand(); or that code could be in a function int f(int *p) which may be called from completely different compilation units (or even across a dynamic library boundary) meaning there's no way for the comp
277.
by dbaupp 8y ago
The model of "pointers are just a number" likely means that even "obvious" optimizations like int i = 0; *p = 10; return i; // becomes *p = 10; return 0; aren't valid, because p could &q
278.
by dbaupp 8y ago
If you're narrowly interpreting an API to mean just the function signature, then sure, if your type system is appropriately restricted then it is computable (although many type systems are Turing complete, meaning this won't be co
279.
by dbaupp 8y ago
I think that's essentially the same point as LBA in a sibling comment. The same intractability-in-practice applies to it: even if your timeout is 10 milliseconds, that's still (tens of) millions of operations on most modern CPUs
280.
by dbaupp 8y ago
That's an interesting idea. It seems like it would be a way for tools to flag "this function is likely to have changed in an interesting way", but changing invariants doesn't necessarily mean the function breaks semver.
281.
by dbaupp 8y ago
Yeah, that seems true. That said, in practice I'm not sure it is too useful (this is a slightly different question to the one originally asked, though). My understanding is the proof of decidability is essentially a pigeonhole principl
282.
by dbaupp 8y ago
No, it isn't computable (that is, correctly determining one of "these functions behave the same" or "these functions behave differently", and not "unknown") in general, as it is equivalent to the halting p
283.
by dbaupp 8y ago
There's not a module-level Safe/Trustworthy/Unsafe division, but as steveklabnik1 says, any potentially-dangerous code has to be placed into an `unsafe` block. One can also forbid the use of any `unsafe` blocks for a crate&#x
284.
by dbaupp 8y ago
Any Python function may use ctypes, any Haskell function may use unsafePerformIO, ..., so all bets are off all the time. I don't think that's a particularly useful point, as is.
285.
by dbaupp 8y ago
It is trivial to use-after-move. The following compiles completely without warnings with the clang on my system (even with -Wall -Weverything), and segfaults: #include <memory> int main() { std::unique_ptr<int> p =
286.
by dbaupp 8y ago
Pretty much only use-after-free and double-free of that list is truly solved by unique_ptr, which is great, but nothing like what you say: - std::move out of a unique_ptr x and "*x" is a null pointer dereference, - take a referen
287.
by dbaupp 8y ago
> In the case of rust we get to call these “compiler bugs” whereas in the C-language world such occurrences are more often labeled “undefined behavior”. C has both compiler bugs and undefined behaviour. Undefined behaviour is an inhere
288.
by dbaupp 8y ago
Yes, that is exactly my point. It's a dangerous feature of the language, or, said another way, has a lot of potential for undefined behaviour. If one is trying to reword the standard to control undefined behaviour, this is one feature
289.
by dbaupp 8y ago
> My understanding is that C has undefined behaviour where there is no universally sensible implementation across all architectures. That's somewhat true for things like signed integer overflow, but it's more than that. For i
290.
by dbaupp 8y ago
I see, I'm sorry. It just seemed like you might not have noticed additional replies to your comment, since you didn't reply there and essentially didn't change what you said.
291.
by dbaupp 8y ago
I suspect it's not possible for most interesting programs, even with whole program analysis. As soon as you start storing pointers behind other pointers, it's (very) hard to keep track of where they came from. There's more di
292.
by dbaupp 8y ago
I think you've flipped the condition: the RH says the Riemann zeta function _only_ has zeros along the line 1/2 + iy. (And, indeed, there are known zeros along this line: 1/2 + 14.135... i.) The Lindelöf hypothesis is, appare
293.
by dbaupp 8y ago
While it's true that processor flaws destroy the assumptions that higher level components (such as any/all programming languages) build on, you don't need to go nearly that far to see unsafety in C++, even using only the
294.
by dbaupp 8y ago
Your first point is of course true, but most statements about the behaviour of code needs to have "assuming no bugs" appended to it, so I'm not sure that it's a particularly interesting point. A more precise interpretati
295.
by dbaupp 8y ago
While the translated code is harder to read, it's much easier to refactor into compiler-checked safe code than the original C. I think doing the translation as part of a larger migration from C to safe Rust is essentially the only de
296.
by dbaupp 8y ago
(It would have been clearer if my original comment said: "The C and the Rust both risk undefined behaviour in the same ways", instead of using an overloaded meaning of unsafe in saying that the C is unsafe.)
297.
by dbaupp 8y ago
No, all memory accesses in C are unsafe in the keyword-in-Rust sense: `unsafe` indicates that an API can be misused to cause undefined behaviour, contrasting to non-`unsafe` code where any potential undefined behaviours will be caught at
298.
by dbaupp 8y ago
I know and agree that unsafe Rust is problematic, but that criticism of this is missing the forest for the trees. The original code is just as unsafe. Refactoring from unsafe Rust into safe Rust manually is likely to be easier than directly
299.
by dbaupp 8y ago
Do you have examples of bugs that it causes when more strictly typed? That is, string + number is an error.
300.
by dbaupp 8y ago
What exactly are you wanting to do with it? There's a few different things might want, and for many of them, there may be alternatives that work just as well, if not better (e.g. instrinsics for the operations like SIMD: https:/

More ›