Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

0xCAFEBABE & 0xFEEDFACE (2003)

radio-weblogs.com

Post reply on HN
Print view View original

41–50 of 126 posts

Re: 0xCAFEBABE & 0xFEEDFACE (2003)

#41

Post by kragen »

cdchn wrote: post #5

I'm surprised they didn't use 0xDECAFBAD for the Java format. Even more interesting is the Wikipedia page https://en.wikipedia.org/wiki/Hexspeak catalogs a delightfully long list of hexspeak words and what they're used for.

in ur-scheme i assigned a magic number to each boxed type as an easy dynamic type test. procedures are 0xca11ab1e, variables moved onto the heap because they were captured by a closure are 0x1ce11ed, strings of text are 0xbabb1e, cons cells consisting of a car and a cdr are 0x2ce11ed, symbol objects used for naming procedures and variables are 0x1abe1, and all other types are unboxed. aside from being enjoyably silly, this was surprisingly helpful when i was single stepping through the code it generated in gdb. hex dumps are a lot easier to read when you do that

http://www.canonical.org/~kragen/sw/urscheme/compiler.scm.ht...

Re: 0xCAFEBABE & 0xFEEDFACE (2003)

#42

Post by [deleted] »

Lammy wrote: post #39
novagameco wrote: post #2

Rust will yell at you if you use specific magic numbers like these edit: yes, 0xCAFEBABE is a warning but 0xFEEDFACE is not: 3405691582 https://github.com/rust-lang/rust/blob/d0ea1d767925d53b2230e...

Reformatted: irb> [184594741, 2880289470, 2881141438, 2965027518, 2976579765, 3203381950, 3405691582, 3405697037, 3735927486, 4027431614, 4276992702].map! { _1.to_s(16) } => ["b00b135", "abadbabe", "abbababe", "b0bababe", "b16b00b5", "beefbabe", "cafebabe", "cafed00d", "deadbabe", "f00dbabe", "feedbabe"]

[deleted]

Re: 0xCAFEBABE & 0xFEEDFACE (2003)

#43

Post by nequo »

bitwize wrote: post #35
cpburns2009 wrote: post #26

Earlier quoted context omitted.

Wouldn't rustc flagging "problematic" numbers prevent arbitrary rust programs from having them in the source?

He means that the style checker only checks for those sorts of numbers in the source code to rustc. But the point remains: there is far, far less tolerance for the sort of humor that objectifies women today, and even laughing at it can get you in trouble as Tim Peters recently found out.

I mean, 0xDDDB00B5 is about as appropriate in a codebase as 0xB166D1C5 or 0x73571C23 would be. Which is to say, it isn’t.

Re: 0xCAFEBABE & 0xFEEDFACE (2003)

#45

Post by onionisafruit »

joshu wrote: post #34
cdchn wrote: post #5

I'm surprised they didn't use 0xDECAFBAD for the Java format. Even more interesting is the Wikipedia page https://en.wikipedia.org/wiki/Hexspeak catalogs a delightfully long list of hexspeak words and what they're used for.

because it would need to be an even number of digits

I count 8 digits

Re: 0xCAFEBABE & 0xFEEDFACE (2003)

#46

Post by onionisafruit »

mikehollinger wrote: post #27

Semi-related story with some insider baseball: There are quite a few memorable words you can spell using 32 or 64 bits—like BA5EBA11. This is the story of me -not- choosing one of those. These bit-pattern words are handy because they’re easy to recognize, especially in a random memory dump. On my first “real” assignment, I was writing real-time embedded C code for a 16-bit processor that communicated with a host micr…

That was a great “Mike says no” moment.

Re: 0xCAFEBABE & 0xFEEDFACE (2003)

#47

Post by physicles »

mikewarot wrote: post #7

0x08675309 also shows up fairly often.

When I worked on Windows Phone during the good ol' days, my team used this for a sort of retail mode assert, for situations that really shouldn't happen. Instantly recognizable. The definition went something like this:

// This is a shout out to that 80s hit. You know the one.

#define E_JENNY_JENNY_WHO_CAN_I_TURN_TO 0x88675309

The 1 in bit 31 was required to signify that it's a Win32 error code. The other high bits are essentially a namespace, which we used correctly for all our other error codes.

Re: 0xCAFEBABE & 0xFEEDFACE (2003)

#49

Post by _tbyi »

Dwedit wrote: post #37

A side benefit of the 2GB address space limit for 32-bit Windows programs is that magic numbers are not valid pointers, and will instantly cause an access violation if used.

I chose my name partially for the 0xFEEEFEEE pattern that the Win32 HeapFree fills memory with in debug mode. I found it when I was very young in the debugger due to this very the reason and I've always loved the words in hex codes since!

Re: 0xCAFEBABE & 0xFEEDFACE (2003)

#50

Post by omoikane »

yongjik wrote: post #29
ryandrake wrote: post #19

Earlier quoted context omitted.

Kind of low-key hilarious that someone thought this was a serious enough issue to actually submit that code. I wonder if there is a written spec that helps to judge which integers should be considered "problematic" and which ones aren't.

Not just that, but they also wrote the numbers in decimal - they didn't even want them in the code as an example of what not to do. Maybe someone was having too much fun and got carried away, but what an odd sense of humor.

> wrote the numbers in decimal

Maybe they just didn't want the checker to flag itself.

I remember there was a similar check inside Google, where any file containing the words "DO NOT SUBMIT" will cause the presubmit check to fail. Naturally the presubmit checker needs to look for that string, but it couldn't trivially include the string as-is because that would prevent the presubmit checker from being submitted.

(Motivation for something like this is that if you inserted some extra logging statements or similar for debugging, you would add "DO NOT SUBMIT" in nearby comments, so that you will remember to remove them later).

Post reply on HN