4 ms·

"the same way some programs currently accidentally depend on freeing memory not immediately overwriting it." Maybe a dumb question, but what do you mean by thi

"the same way some programs currently accidentally depend on freeing memory not immediately overwriting it." Maybe a dumb question, but what do you mean by this? Could you give a C/C++ pseudo-example?

Someone 4y ago
Not the poster, but it’s fairly easy to accidentally do the equivalent of free(f); f->close(); in code that does a few malloc, if/else’s, etc. between those calls. Stuff like that gets hard to spot in more complex code, especially in the presence of C++ copy constructors, move constructors, etc, where the compiler helpfully inserts that call to free for you. Bugs in copy constructors also can lead to double frees when the destructors of an object and its copy both call delete on a pointer that they think they exclusively own. Between those two destructor calls, you can easily get a use after free. Example: https://stackoverflow.com/a/64014035 https://stackoverflow.com/a/64014035 If the allocator doesn’t change the content of freed blocks, such bugs can go unnoticed, making the program “accidentally depend on freeing memory not immediately overwriting it”.
- ajross 4y ago
  > especially in the presence of C++ copy constructors, move constructors, etc, You only mean the former, not both. The only reason for the existence of the giant rats' nest of complexity that is C++ move semantics is eliminating this particular mistake.
wnissen 4y ago
Ooh, I have a good one for this. If you have a C++ `std::string` object passing into a C API that takes a null-terminated `char *`, there's a convenience method `std::string::c_str()` to produce the C string from the C++ one. char const* inputFilename = std::string("path/to/file").c_str(); call_to_C_API(inputFilename); Boom. You can typically access `inputFilename` until the next allocation on the stack, but it will almost always go bad quickly. This isn't allocation on the heap, which usually requires another level of indirection, but you get the idea.
- cesarb 4y ago
  > This isn't allocation on the heap, which usually requires another level of indirection, but you get the idea. Isn't it allocating in the stack due to the "small string optimization"? Making string contents longer (or using a C++ standard library which doesn't have a "small string optimization" in the first place) would be enough to have it be allocated in the heap instead.
  - verall 4y ago
    No, with longer string contents the std::string will internally allocate and store on the heap, but as the containing std::string is a temporary it will be pop'd of the stack (stack pointer moved, which is why it works "sometimes") and its destructor called at the end of the statement (at the semicolon), freeing the heap allocated memory (which, as parents are discussing, may still work because nothing has yet overwritten the recently freed memory). Changing it to: call_to_C_API(std::string("path/to/file").c_str()); Makes it valid because the std::string object will live until the semicolon.
- deleted 4y ago
  [deleted]

Someone 4y ago

Not the poster, but it’s fairly easy to accidentally do the equivalent of free(f); f->close(); in code that does a few malloc, if/else’s, etc. between those calls. Stuff like that gets hard to spot in more complex code, especially in the presence of C++ copy constructors, move constructors, etc, where the compiler helpfully inserts that call to free for you. Bugs in copy constructors also can lead to double frees when the destructors of an object and its copy both call delete on a pointer that they think they exclusively own. Between those two destructor calls, you can easily get a use after free. Example: https://stackoverflow.com/a/64014035 https://stackoverflow.com/a/64014035 If the allocator doesn’t change the content of freed blocks, such bugs can go unnoticed, making the program “accidentally depend on freeing memory not immediately overwriting it”.

ajross 4y ago
> especially in the presence of C++ copy constructors, move constructors, etc, You only mean the former, not both. The only reason for the existence of the giant rats' nest of complexity that is C++ move semantics is eliminating this particular mistake.

wnissen 4y ago

Ooh, I have a good one for this. If you have a C++ `std::string` object passing into a C API that takes a null-terminated `char *`, there's a convenience method `std::string::c_str()` to produce the C string from the C++ one. char const* inputFilename = std::string("path/to/file").c_str(); call_to_C_API(inputFilename); Boom. You can typically access `inputFilename` until the next allocation on the stack, but it will almost always go bad quickly. This isn't allocation on the heap, which usually requires another level of indirection, but you get the idea.

cesarb 4y ago
> This isn't allocation on the heap, which usually requires another level of indirection, but you get the idea. Isn't it allocating in the stack due to the "small string optimization"? Making string contents longer (or using a C++ standard library which doesn't have a "small string optimization" in the first place) would be enough to have it be allocated in the heap instead.
- verall 4y ago
  No, with longer string contents the std::string will internally allocate and store on the heap, but as the containing std::string is a temporary it will be pop'd of the stack (stack pointer moved, which is why it works "sometimes") and its destructor called at the end of the statement (at the semicolon), freeing the heap allocated memory (which, as parents are discussing, may still work because nothing has yet overwritten the recently freed memory). Changing it to: call_to_C_API(std::string("path/to/file").c_str()); Makes it valid because the std::string object will live until the semicolon.
deleted 4y ago
[deleted]