5 ms·

> If malloc is accidentally being called with a pointer instead that would be an error Not true, just tried it in MSVC and it compiled fine but with a warning

> If malloc is accidentally being called with a pointer instead that would be an error Not true, just tried it in MSVC and it compiled fine but with a warning on conflicting types. "HTTP" is of type const char* and sizeof(size_t) == sizeof(const char *). Doesn't matter if its 32 or 64, I'm not aware of a platform where that isn't the case. > but this story is about an instance where malloc was accidentally being called with the first bits of a string instead If that's the case, then it should have been something along the lines of *"HTTP" instead.

anonymoushn 3y ago
> Not true, just tried it in MSVC and it compiled fine but with a warning on conflicting types. If I meant that it would cause the compiler to report an error then I would have written that. > If that's the case, then it should have been something along the lines of *"HTTP" instead. We can say that they really should have written memcpy to get the string literal into the size_t or we can accept that sometimes people use language imprecisely and expect readers to make an effort to understand rather than make an effort not to understand.
- PaulCarrack 3y ago
  > or we can accept that sometimes people use language imprecisely and expect readers to make an effort to understand rather than make an effort not to understand. I don't disagree with you there, however, things like pointers and string literals (and what they actually represent) in my experience are a source of confusion to junior systems engineers. I'd imagine that the intended reader is someone who wants to be a systems engineer, not someone who is already a systems engineer. I expect the reader to be motivated to understand (after all, they are reading the article) but not understand and get confused because of the imprecise language, especially in the case in programming where precision matters (or the code doesn't work).
jfoutz 3y ago
or a union. or, like, a bug. it would be neat if people ran -Wall -Wpedantic, and valgrind. but, you know, they don't. That's kind of where people the author talked about think the magic of "systems engineer" comes from. I'm sure you've had that one team mate who took like 5 tries to pass code review. Not every team has a you, and crazy things land in prod, because that one team mate didn't have you to keep them correct.
yuliyp 3y ago
The situation in question involved a response from some other server. That server was supposed to speak some binary protocol which had a 32-bit length field at the start of the response. Instead the program which did the giant malloc accidentally tried to connect to an HTTP server. It blindly trusted that it would receive something in that binary protocol, so tried to interpret the first 4 bytes of the response as a length, and then proceeded to try and set aside enough of a buffer to handle that size.
jcranmer 3y ago
> "HTTP" is of type const char* and sizeof(size_t) == sizeof(const char *). Doesn't matter if its 32 or 64, I'm not aware of a platform where that isn't the case. CHERI has sizeof(pointer) = 16, sizeof(size_t) = 8. It's probably the most widespread system where sizeof(uintptr_t) != sizeof(size_t) (and it's admittedly a niche system).

anonymoushn 3y ago

> Not true, just tried it in MSVC and it compiled fine but with a warning on conflicting types. If I meant that it would cause the compiler to report an error then I would have written that. > If that's the case, then it should have been something along the lines of *"HTTP" instead. We can say that they really should have written memcpy to get the string literal into the size_t or we can accept that sometimes people use language imprecisely and expect readers to make an effort to understand rather than make an effort not to understand.

PaulCarrack 3y ago
> or we can accept that sometimes people use language imprecisely and expect readers to make an effort to understand rather than make an effort not to understand. I don't disagree with you there, however, things like pointers and string literals (and what they actually represent) in my experience are a source of confusion to junior systems engineers. I'd imagine that the intended reader is someone who wants to be a systems engineer, not someone who is already a systems engineer. I expect the reader to be motivated to understand (after all, they are reading the article) but not understand and get confused because of the imprecise language, especially in the case in programming where precision matters (or the code doesn't work).

jfoutz 3y ago

or a union. or, like, a bug. it would be neat if people ran -Wall -Wpedantic, and valgrind. but, you know, they don't. That's kind of where people the author talked about think the magic of "systems engineer" comes from. I'm sure you've had that one team mate who took like 5 tries to pass code review. Not every team has a you, and crazy things land in prod, because that one team mate didn't have you to keep them correct.

yuliyp 3y ago

The situation in question involved a response from some other server. That server was supposed to speak some binary protocol which had a 32-bit length field at the start of the response. Instead the program which did the giant malloc accidentally tried to connect to an HTTP server. It blindly trusted that it would receive something in that binary protocol, so tried to interpret the first 4 bytes of the response as a length, and then proceeded to try and set aside enough of a buffer to handle that size.

jcranmer 3y ago

> "HTTP" is of type const char* and sizeof(size_t) == sizeof(const char *). Doesn't matter if its 32 or 64, I'm not aware of a platform where that isn't the case. CHERI has sizeof(pointer) = 16, sizeof(size_t) = 8. It's probably the most widespread system where sizeof(uintptr_t) != sizeof(size_t) (and it's admittedly a niche system).