3 ms·

I guess you are "the one". This means you won't fail this stuff and this discussion is not for you, it is for the rest of us who would. https://rachelbythebay.

by jraph 2y ago

I guess you are "the one". This means you won't fail this stuff and this discussion is not for you, it is for the rest of us who would. https://rachelbythebay.com/w/2018/04/28/meta/ https://rachelbythebay.com/w/2018/04/28/meta/

bsenftner 2y ago
I'm advocating not to wing it, design up front and then follow that design. When the design is found lacking, redesign with the entire system in mind. Basically, all I'm saying is do not take short cuts, they are not short cuts. Your project may finish faster, but you are harming yourself as a developer.
- deleted 2y ago
  [deleted]
- jraph 2y ago
  I had initially written a very snarky comment here, but this one [1] actually expresses my view quite well in a respectful way, I would answer with this. I guess the discussion can continue there as well. [1] https://news.ycombinator.com/item?id=43387334#43388305 https://news.ycombinator.com/item?id=43387334#43388305
bcrl 2y ago
I agree with the grandparent mostly because the article doesn't have any real world applications. Forgetting to free memory that is allocated and then used inside of a function is the rarest kind of memory management bug that I have run into in large code bases. It's frequently obvious if you read the function and are following good practices by making the code clean and easy to read / follow. The ones that bite are typically a pointer embedded in some object in the middle of a complicated data structure that persists after a function returns. Reference counting may or may not be involved. It may be a cache of some sort to reduce CPU overhead from recomputing some expensive operation. It's rarely a chunk of memory that has just been allocated. To actually recover the lost memory in those cases is going to need something more complicated like garbage collection. But garbage collection is really hard to retrofit into C when libraries are involved as who knows what kind of pointer manipulation madness exists inside other people's code. What would be really interesting is if someone made a C compiler that replaced pointers with fat pointers that could be used to track references and ensure they are valid before dereferencing. Sure, it would be an ABI bump equivalent to implementing a new architecture along with plenty of fixups in legacy C code, but we've done that before. The security pendulum has swung over to the point that rebuilding the world would be considered worthwhile as compared to where we stood 10-15 years ago. It'd certainly be a lot of work to get that working compared to a simple hack per the Fine Article, but it would have real value.
- jraph 2y ago
  Yep, okay, I mostly agree with you on this.

by jraph 2y ago

bsenftner 2y ago

I'm advocating not to wing it, design up front and then follow that design. When the design is found lacking, redesign with the entire system in mind. Basically, all I'm saying is do not take short cuts, they are not short cuts. Your project may finish faster, but you are harming yourself as a developer.

deleted 2y ago
[deleted]
jraph 2y ago
I had initially written a very snarky comment here, but this one [1] actually expresses my view quite well in a respectful way, I would answer with this. I guess the discussion can continue there as well. [1] https://news.ycombinator.com/item?id=43387334#43388305 https://news.ycombinator.com/item?id=43387334#43388305

bcrl 2y ago

I agree with the grandparent mostly because the article doesn't have any real world applications. Forgetting to free memory that is allocated and then used inside of a function is the rarest kind of memory management bug that I have run into in large code bases. It's frequently obvious if you read the function and are following good practices by making the code clean and easy to read / follow. The ones that bite are typically a pointer embedded in some object in the middle of a complicated data structure that persists after a function returns. Reference counting may or may not be involved. It may be a cache of some sort to reduce CPU overhead from recomputing some expensive operation. It's rarely a chunk of memory that has just been allocated. To actually recover the lost memory in those cases is going to need something more complicated like garbage collection. But garbage collection is really hard to retrofit into C when libraries are involved as who knows what kind of pointer manipulation madness exists inside other people's code. What would be really interesting is if someone made a C compiler that replaced pointers with fat pointers that could be used to track references and ensure they are valid before dereferencing. Sure, it would be an ABI bump equivalent to implementing a new architecture along with plenty of fixups in legacy C code, but we've done that before. The security pendulum has swung over to the point that rebuilding the world would be considered worthwhile as compared to where we stood 10-15 years ago. It'd certainly be a lot of work to get that working compared to a simple hack per the Fine Article, but it would have real value.

jraph 2y ago
Yep, okay, I mostly agree with you on this.