>Eric Levenez wrote: >: > anybody know where it came from, ie. why DEADBEEF?? > >The DEADBEEF Hex value did indeed start with AIX Version2 on the RT. >Memory fill of just malloc'ed pages are filled with that pattern. > >: Sometime it is better to have a pattern other that 0x00000000 because >: it is simpler to track wrong pointers. By default, all memory are >: filled with this pattern, so it is simpler to see if someone wrote >: in it or not. > >Indeed. Tracing down uninitialized pointers is a lot easier. > >: The DEADBEEF comes from IBM, the name was given because IBM is in Texas. > >ACTUALLY... only the WORKSTATION division was in Austin Texas.. IBM itself >is widely scattered across the US and the world. > >Is'nt Armonk, NY. the home of IBM? Ah, the perennial "deadbeef" thread... this *is* in the AIX FAQ, by the way. (Item 2.16, which is in Part 4 of the FAQ in the version I currently have.) As I recall from my IBM days (in Cambridge, MA), either early RTs or early RS/6Ks (possibly both -- can't remember for sure) had in place of the IBM logo a little badge with a guy in a cowboy hat and a couple of stars -- a sort of internal logo for the Austin group. But deadbeef is there as much because it's a word that can be "spelled" in hex as for any other reason. AIX also sports the "0xbadca11" for invalid code addresses and "0xdeadc0de" for some other condition (I don't believe those are in the FAQ). There are, of course, many English words that can more-or-less be spelled out in hex; I posted a list when this subject came up a couple of years ago. For example: ------ from <3vj1a6$j3a@hyperion.mfltd.co.uk>, 95/07/31 ------ When you start using 1 as "l" and 0 as "o", and allowing shorter words by omitting leading 0s (as in 0xbadca11), possibilites abound: - 0xacc01ade, which you might initialize memory to if you want to reward your out-of-bounds checking code - 0xb01dface to make those memory errors stand out - 0xaffab1e if it's not really an important memory error - 0xdebac1e if it is - 0xa1fa1fa to 0xfeed all that 0xbeef before it dies - 0xfa110ff when you trace the stack back a little too far... - 0x0ff10ad if you're using an ICE - 0xbabb1e because "GIGO" is tough to represent in hex - 0xc0ffee when it's time for an extra cup (try the 0xcafe) - 0xc0bb1e, which is how you put your code together, unless - 0xd00d1e and 0xdabb1e is - 0xdec0de, since you didn't 0xc0de right in the first place - 0xfacade and 0xfeeb1e -- more trenchant analysis The end result, of course, is that you're going to 0xcedeface if these show up in your code. ------ end quote ------ I found most of these just by grep'ing through /usr/dict/words with the appropriate substitutions. And people complain that there aren't enough games for Unix... Some languages are tougher, even allowing Romanization and omitting diacritical marks. Take Japanese, for example. If we use a *very* liberal and nonstandard Romanization, we might allow the following "hex romaji": - a and e are taken directly from hex - use 1 for "i" and 0 for "o" - use c for "ka", etc. -- except that no Romanization would pronounce "ce" and "ci" correctly, which leaves us with just "ca" and "c0" in ka-gyoo - use 6 for "ga", etc., treating 6 as a capital G - use b for "ba", etc. - use d for "da", etc. - use 1 for "ra", etc., transliterating Japanese ra-gyoo with an "l" instead of an "r", though this makes "ri" almost unrecognizable (it comes out as "11") - use 5 for "sa", etc., though this is a real stretch - transliterate phonemes like "shi" without the English double consonant: "si", etc. This lets us use "51" for "shi" (sort of) and "c1" for "chi". - we might, in some circumstances, allow eliding a final "u" sound, as is often done in spoken Japanese This gives us Japanese phonemes: a, i, e, o, ka, ko, ga, gi, ge, go, ba, bi, be, bo, da, de, do, ra, ri, re, ro, sa, si, se, so, chi, and at the end of a word ku, gu, fu, ru, su So, for example, we might have: - 0xEE500DA ("ee, soo da" -- "yes, that's right") - 0xBE1C0C ("beikoku" -- one of the words for the US) Other words (and languages) are left as an exercise for the reader. Michael Wojcik mww@microfocus.com AAI Development, Micro Focus Inc. Department of English, Miami University