Hacker News Reader

Comment by PaulCarrack | Hacker News Reader

> 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.

View on HN

This is shorthand pseudocode referring to a story that she has previously written up: 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.

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.

> 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.

> 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.

> 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).

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.

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.

> "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).

I don't know why you're getting downvoted.

It's likely something like

malloc('HTTP') // note the single quotes

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).

> 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.

I skipped that last line too. Thanks for pointing it out. I now do know why they're being downvoted.

Reply on news.ycombinator.com