acconsta

10 ms·

61.
by acconsta 11y ago
Great! Please implement them in Rust as soon as possible. But until then, Rust's approach is runtime bounds checking.
62.
by acconsta 11y ago
For the record, I don't have enough karma to downvote. >Linux is not inextricably tied to any single language It is pretty tightly coupled to GCC, which, as you know, is a C compiler. Some people are working on supporting Clang, but
63.
by acconsta 11y ago
"might" is the key word there though. What if the array has a statically known size, like the code sample in the email? I suppose it could just be for consistency.
64.
by acconsta 11y ago
>the cost of runtime bounds checking in real programs is indistinguishable from noise Can you show us the benchmarks for that?
65.
by acconsta 11y ago
No. There's only one language you can write a patch for the Linux network stack in — C. "Move to Rust!" is not a productive or helpful suggestion, unless you have an massive army of programmers ready to port Linux to Rust.
66.
by acconsta 11y ago
Yes, but why does the standard have that bug?
67.
by acconsta 11y ago
Yeah. But why is that the behavior specified by the standard?
68.
by acconsta 11y ago
If you're using iterators, you don't have to worry about buffer overflow. But every A[i] random access needs to be bound checked.
69.
by acconsta 11y ago
If I write: void example(int a[10]); Why can't the compiler tell a is an int array of size 10 instead of a pointer?
70.
by acconsta 11y ago
But the size of C89 arrays is fixed and known at compile time. Why would the length need to be passed?
71.
by acconsta 11y ago
>The point is a language like Rust has built-in bounds checking... As does C++. See e.g. vector.at and libstdc++ debug mode: https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.h... The difference i
72.
by acconsta 11y ago
>We need to move forward to Rust In fairness, C++ containers know their size. And Rust's solution to buffer overflows is the same as every other language — run time bounds checking.
73.
by acconsta 11y ago
Does anyone know why array arguments decay to pointers?
74.
by acconsta 11y ago
"So you confer with DataStax for a while, and they manage to reproduce and fix the bug: #6029 (Lightweight transactions race render primary key useless), and #5985 (Paxos replay of in progress update is incorrect). You start building p
75.
by acconsta 11y ago
Yeah, I was wondering about that. It looks like you guys have done some brilliant work with the storage engine, but reimplementing all the distributed logic is another (possibly bigger) project.
76.
by acconsta 11y ago
Basically mapping the device registers into user space and doing exactly what the kernel would do, but without the syscall overhead. Some researchers made a big splash at OSDI by doing this securely: http://people.inf.ethz.ch&#x2
77.
by acconsta 11y ago
Are there any recent comparative benchmarks of hypertable? I looked around but couldn't find any.
78.
by acconsta 11y ago
That's what I thought. I think deploying something like this would be easier than the parent comment suggests.
79.
by acconsta 11y ago
Right, I should add that it was two years ago. My point is that the age of a project has nothing to do with the correctness of its Paxos implementation.
80.
by acconsta 11y ago
Strongly agreed. It's great that these HPC techniques are finally starting to trickle down.
81.
by acconsta 11y ago
It's exciting to finally see this. Cassandra's strengths were in its distributed architecture (no master, tunable consistency, etc.). The database engine itself has always been a bit of a mess ( https://issues.apache.org
82.
by acconsta 11y ago
Agreed, but which architectural features are you referring to?
83.
by acconsta 11y ago
Honestly, Cassandra's Jepsen didn't set a high bar: https://aphyr.com/posts/294-call-me-maybe-cassandra/
84.
by acconsta 11y ago
How big do you have to be to lease hardware?
85.
by acconsta 11y ago
Placer looks interesting. I'll try it out. >When you're writing a kernel you're not supposed to be using the standard library at all, just libcore (which exists for this purpose). The same issue exists in C++. Not quite. C
86.
by acconsta 11y ago
Oh OK, I definitely could have written that better. From what I can tell, M:N threading has been thoroughly abandoned by Linux, but it might be worth revisiting given the horrendous I/O scaling of Linux kernel threads. I would imagine
87.
by acconsta 11y ago
I wonder how many of these could be implemented in clang tidy: http://clang.llvm.org/extra/clang-tidy/index.html
88.
by acconsta 11y ago
Right, duplicating every method that allocates also isn't very elegant. But could Box and containers be polymorphic on an OOM handling trait? Alternatively, one could imagine an OOM-safe container that returns results, and a convenienc
89.
by acconsta 11y ago
That code sample is really helpful, thanks. But doesn't that seem kind of redundant? Box and std containers are great as is, except for the one line that aborts on OOM. Would it be possible to use traits to choose OOM behavior at com
90.
by acconsta 11y ago
Oh, OK. When I hear syntactic sugar, I think of like a macro. Thanks though, I'm glad this is on the core team's radar.

More ›