btrask

7 ms·

1.
by btrask 5y ago
I might be the last person to realize this, but did Microsoft name it .NET because they already had COM?
2.
by btrask 5y ago
This article does not undermine its own point. In fact, very, very few articles ever undermine their own point. In order to undermine your own point it means you've failed to construct a logical chain of thought. But that is what peo
3.
by btrask 6y ago
I didn't like Regehr's proposal because I don't want a friendly dialect of C. I mostly just want C the way it worked up until, say, GCC 4.x. I don't know specifically how to fix the standard, although I've been thin
4.
by btrask 6y ago
Or... the standard just has bugs which could be fixed. Bugs meaning: being out of line with the history of C and large amounts of C code in the wild. The more people beat the standard drum, the worse things will get until the standard itsel
5.
Tower of Babel(en.wikipedia.org)
1 points by btrask 6y ago|0 comments
6.
by btrask 6y ago
Yeah, in C you need to use assertions (or simple checks) for things that might be null. That said the compiler isn't infinitely smart (thank god) and complex null derefs will "safely" make it to runtime. (What a sad world we&
7.
by btrask 6y ago
If you are transferring ownership, you would do p2 = p1; p1 = NULL; However if you are intentionally doing multiple ownership, then yes you can still have problems.
8.
by btrask 6y ago
Green threads.
9.
by btrask 6y ago
I see now, I misunderstood your original post. You were saying async/await is necessary because futures work badly, not because all the alternatives (i.e. locks) work badly. Sorry, my mistake! Edit to add: futures work badly in eve
10.
by btrask 6y ago
Whether it's kernel threads or green threads, the same patterns (locks, etc) are possible. Locks are supposed to be the borrow checker's bread and butter, because it can guarantee they are held before accessing shared state. But n
11.
by btrask 6y ago
Wait, what? What happened to "fearless concurrency"? I thought this was supposed to be one of the borrow checker's selling points! https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.h...
12.
by btrask 6y ago
So over the last thousand years salt has been a hyper-inflationary asset, and you're trying to tell me I'm rich for owning some?
13.
by btrask 6y ago
This article is such a great opportunity for introspection ("what do we need in order to do better?"). It's too bad that the top comment has turned it into an opportunity for egotism ("they need us!").
14.
by btrask 6y ago
Very reasonable! Thank you for the discussion :)
15.
by btrask 6y ago
Taking a pointer-to-pointer is intentional to make it clear that the pointer will be modified. That's actually the most important difference from nn3's version IMHO.
16.
by btrask 6y ago
Good points, thank you for explaining! I can see an argument for wrapping it in a macro so you can turn off nulling in debug builds (ASan might even have hooks so you can automate this, I know Valgrind does). But use-after-free is worse tha
17.
by btrask 6y ago
I tried making it a plain function at one point but ran into some weirdness around using void * * with certain arguments (const buffers?). You don't want to accept plain void * because it's too easy to pass a pointer instead of a
18.
by btrask 6y ago
do {} while(0) is a common idiom for macros in C, because it consumes the trailing semicolon, which a bare {} block doesn't do. if(x) MACRO(); else something(); expands to if(x) { ... }; // Error! else
19.
by btrask 6y ago
I appreciate you defending me, but I don't think he was trying to be dishonest.
20.
by btrask 6y ago
I don't think that's fair in this case because nulling out pointers isn't the first line of defense. If you forget to do it once, it's not going to cause a bug in and of itself. You can easily grep the code periodically
21.
by btrask 6y ago
Help me out here, because I'm really trying to understand. Are you saying that dangling pointers that blow up if you double-free them is an "automatic check"? If not, what kind of automatic check are you talking about? If the
22.
by btrask 6y ago
In C you can use [0] for postfix pointer dereferencing.
23.
by btrask 6y ago
Here's the actual macro I (sometimes) use: #define FREE(ptrptr) do { \ __typeof__(ptrptr) const __x = (ptrptr); \ free(*__x); *__x = NULL; \ } while(0) There might be a better way of doing it though. Also,
24.
by btrask 6y ago
Every problem can be solved in many different ways. If you think you've already got use-after-free bugs under control, then more power to you! You absolutely have to concentrate your effort on whatever your biggest problems are. But I&
25.
by btrask 6y ago
All code is full of vulnerabilites. If you say your code isn't, then I'm sure it is. I just do the best I can to keep the error rate as low as possible. But it's a rate, and it's never zero. Also, it's not just
26.
by btrask 6y ago
It's defensive coding. Do you think defensive driving is 'sweeping problems under the carpet'? (It is, but it's still useful...) I use every tool at my disposal. Sanitizers, static analyzers... and also not leaving dangl
27.
by btrask 6y ago
Well, dangling pointers are also easy to forget... Yes, it requires some discipline. Good code requires discipline, doesn't it? The trick of checking that buffers are zeroed is purely a debugging tool, so it's okay if it doesn&#x2
28.
by btrask 6y ago
Here's a trick that will actually help produce more secure and reliable programs. *outArg = myPtr; myPtr = NULL; free(aPtr); aPtr = NULL; Set your pointers to null when you free them! Set them to null when you transfer own
29.
by btrask 6y ago
Well, they tried to write a new browser engine in Rust but gave up and got laid off. A few pieces got integrated into Firefox but the browser is still wildly insecure (cf. the article). Turns out "Rewrite it in Rust" is actually r
30.
by btrask 6y ago
They tried that. It was called Servo, and it was Rust's raison d'etre. It failed.

More ›