4 ms·

> malloc(1213486160) is really malloc(0x48545450) is really malloc("HTTP") No it's not / that's not how C works. malloc("HTTP") is malloc of the address of a s

> malloc(1213486160) is really malloc(0x48545450) is really malloc("HTTP") No it's not / that's not how C works. malloc("HTTP") is malloc of the address of a string literal in memory. If "HTTP" is at address 0x11223344 then it's malloc(0x11223344). So it's the address of where ever the "HTTP" string is in the binary not the characters themselves. It's kind of a weird way to say that you can convert decimal to hexadecimal in your head. I also wouldn't use malloc as the example to demonstrate that talent, it makes no sense that way. Perhaps becoming a systems engineer should involve learning C first... Don't always trust what you read.

anonymoushn 3y ago
malloc takes a size_t indicating the desired size of the allocation. If malloc is accidentally being called with a pointer instead that would be an error, but this story is about an instance where malloc was accidentally being called with the first bits of a string instead, apparently on a big-endian system where size_t is 32 bits. Hope that helps.
- PaulCarrack 3y ago
  > 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).
abbeyj 3y ago
This is shorthand pseudocode referring to a story that she has previously written up: https://rachelbythebay.com/w/2016/02/21/malloc/ https://rachelbythebay.com/w/2016/02/21/malloc/ . I suppose one could write `malloc(__builtin_bswap32(*(uint32_t*)"HTTP"))` instead but that seems overly verbose for an aside that's not meant to be compiled.
underdeserver 3y ago
I don't know why you're getting downvoted. It's likely something like malloc('HTTP') // note the single quotes or const char* s = "HTTP"; malloc(*s); Also I would expect the string to be reversed if she's working on a little-endian system (which the most common ones today are, including Intel 64 bit and ARM64).
- jraph 3y ago
  > I don't know why you're getting downvoted. I didn't, but probably because they may read like they are lecturing Rachel. Which looks bad in itself, but feels extra ridiculous for anyone familiar with Rachel's blog. She pretty much knows how malloc and C work. She probably could write her own malloc without sweating. Worse still, OP is seems to try to imply that Rachel is trying to lie and brag about some irrelevant gift (decoding hexadecimal in her head) by making up examples. Let's just say that it's not very charitable and it's also against HN guidelines. OP could just have expressed their surprise and asked for some clarification instead. They are not reading "is really" correctly and not considering that Rachel is taking some shortcuts so the article remains simple and enjoyable to read, as most good writers do, which in the end makes OP's whole comment somewhat moot. See abbeyj's reply for more context. The full explanation is in Rachel's article abbeyj points to, there's no need to guess. edit: I had skipped the last line of OP's comment. It's just outright mean. No wonder they are downvoted actually.
  - underdeserver 3y ago
    I skipped that last line too. Thanks for pointing it out. I now do know why they're being downvoted.

anonymoushn 3y ago

malloc takes a size_t indicating the desired size of the allocation. If malloc is accidentally being called with a pointer instead that would be an error, but this story is about an instance where malloc was accidentally being called with the first bits of a string instead, apparently on a big-endian system where size_t is 32 bits. Hope that helps.

PaulCarrack 3y ago
> 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).

abbeyj 3y ago

This is shorthand pseudocode referring to a story that she has previously written up: https://rachelbythebay.com/w/2016/02/21/malloc/ https://rachelbythebay.com/w/2016/02/21/malloc/ . I suppose one could write `malloc(__builtin_bswap32(*(uint32_t*)"HTTP"))` instead but that seems overly verbose for an aside that's not meant to be compiled.

underdeserver 3y ago

I don't know why you're getting downvoted. It's likely something like malloc('HTTP') // note the single quotes or const char* s = "HTTP"; malloc(*s); Also I would expect the string to be reversed if she's working on a little-endian system (which the most common ones today are, including Intel 64 bit and ARM64).

jraph 3y ago
> I don't know why you're getting downvoted. I didn't, but probably because they may read like they are lecturing Rachel. Which looks bad in itself, but feels extra ridiculous for anyone familiar with Rachel's blog. She pretty much knows how malloc and C work. She probably could write her own malloc without sweating. Worse still, OP is seems to try to imply that Rachel is trying to lie and brag about some irrelevant gift (decoding hexadecimal in her head) by making up examples. Let's just say that it's not very charitable and it's also against HN guidelines. OP could just have expressed their surprise and asked for some clarification instead. They are not reading "is really" correctly and not considering that Rachel is taking some shortcuts so the article remains simple and enjoyable to read, as most good writers do, which in the end makes OP's whole comment somewhat moot. See abbeyj's reply for more context. The full explanation is in Rachel's article abbeyj points to, there's no need to guess. edit: I had skipped the last line of OP's comment. It's just outright mean. No wonder they are downvoted actually.
- underdeserver 3y ago
  I skipped that last line too. Thanks for pointing it out. I now do know why they're being downvoted.