Setting enum values to 4-byte strings - why?

I saw code similar to this in the Mac OS SDK:

enum {
   kAudioFileStreamProperty_ReadyToProducePackets    = 'redy',
   kAudioFileStreamProperty_FileFormat               = 'ffmt',
   kAudioFileStreamProperty_DataFormat               = 'dfmt',
   kAudioFileStreamProperty_FormatList               = 'flst',
   kAudioFileStreamProperty_MagicCookieData          = 'mgic',
   kAudioFileStreamProperty_AudioDataByteCount       = 'bcnt',
   kAudioFileS开发者_运维技巧treamProperty_AudioDataPacketCount     = 'pcnt',
   kAudioFileStreamProperty_MaximumPacketSize        = 'psze',
   kAudioFileStreamProperty_DataOffset               = 'doff',
   kAudioFileStreamProperty_ChannelLayout            = 'cmap',
   kAudioFileStreamProperty_PacketToFrame            = 'pkfr',
   kAudioFileStreamProperty_FrameToPacket            = 'frpk',
   kAudioFileStreamProperty_PacketToByte             = 'pkby',
   kAudioFileStreamProperty_ByteToPacket             = 'bypk',
   kAudioFileStreamProperty_PacketTableInfo          = 'pnfo',
   kAudioFileStreamProperty_PacketSizeUpperBound     = 'pkub',
   kAudioFileStreamProperty_AverageBytesPerPacket    = 'abpp',
   kAudioFileStreamProperty_BitRate                  = 'brat'
};

It's the first time I've seen this - I assume the compiler assigns the 32-bit integer equivalent of the strings to the enum values. I cannot think of a single good reason why this might be preferred over using simple integers. It looks hideous in a debugger (how do you tell which of these values corresponds to 1919247481?) and makes debugging just hard in general.

So, is there any reason where assigning such strings to enum values actually makes sense.

It's precisely because of the debugger that you would do such a thing. Most debuggers can show memory as ASCII, something like:

00000000: 12 34 56 78 90 12 45 67 12 34 56 78 89 ab cd ef .4Vx..Eg.4Vx....  

Being able to identify structures, constants, and so forth by just looking at a memory dump is pretty handy. Particularly if one of these structures and/or constants overwrote a bunch of memory you didn't want it to....

That format is called a four-character code, or FOURCC. Incidentally, it originated from Apple with the Macintosh, and it's pretty convenient if you can view memory in ASCII characters. It's also a convenient way to embed 4-byte identifiers in a file, although it will look backwards given a little-endian convention.

In gdb, you can check the constant by doing:

print (char[4]) val

Although on Intel and other little-endian systems the characters will be reversed. Older Macintosh computers that used PowerPC or 68k processors would show the characters in the correct order when viewing a memory dump.