15

I am working with Apple's ScriptingBridge framework, and have generated a header file for iTunes that contains several enums like this:

typedef enum {
    iTunesESrcLibrary = 'kLib',
    iTunesESrcIPod = 'kPod',
    iTunesESrcAudioCD = 'kACD',
    iTunesESrcMP3CD = 'kMCD',
    iTunesESrcDevice = 'kDev',
    iTunesESrcRadioTuner = 'kTun',
    iTunesESrcSharedLibrary = 'kShd',
    iTunesESrcUnknown = 'kUnk'
} iTunesESrc;

My understanding was that enum values had to be integer-like, but this definition seems to violate that rule. Furthermore, it seems as though treating these enum values as integers (in an NSPredicate, for example) doesn't do the right thing.

I added the enum declaration above to a C file with an empty main function, and it compiled using i686-apple-darwin9-gcc-4.0.1. So, while these kinds of enums may not conform to the C standard (as Parappa points out below), they are at least being compiled to some type by gcc.

So, what is that type, and how can I use it, for instance, in a format string?

Gavin Brock
  • 5,027
  • 1
  • 30
  • 33
Evan DiBiase
  • 1,104
  • 9
  • 16

4 Answers4

18

C99, TC3 reads:

6.4.4.4 §2:

An integer character constant is a sequence of one or more multibyte characters enclosed in single-quotes, as in 'x'. [...]

6.4.4.4 §10:

An integer character constant has type int. The value of an integer character constant containing a single character that maps to a single-byte execution character is the numerical value of the representation of the mapped character interpreted as an integer. The value of an integer character constant containing more than one character (e.g., 'ab'), or containing a character or escape sequence that does not map to a single-byte execution character, is implementation-defined. If an integer character constant contains a single character or escape sequence, its value is the one that results when an object with type char whose value is that of the single character or escape sequence is converted to type int.

In most implementations, it's safe to use integer character constants of up to 4 one-byte characters. The actual value might differ between different systems (endianness?) though.

This is actually already defined in the ANSI-C89 standard, section 3.1.3.4:

An integer character constant is a sequence of one or more multibyte characters enclosed in single-quotes, as in 'x' or 'ab'. [...]

An integer character constant has type int. The value of an integer character constant containing a single character that maps into a member of the basic execution character set is the numerical value of the representation of the mapped character interpreted as an integer. The value of an integer character constant containing more than one character, or containing a character or escape sequence not represented in the basic execution character set, is implementation-defined. In particular, in an implementation in which type char has the same range of values as signed char, the high-order bit position of a single-character integer character constant is treated as a sign bit.

Christoph
  • 164,997
  • 36
  • 182
  • 240
6

The single quotes indicate characters, rather than strings in C. So each of the enums will have a 32 bit value consisting of the character codes for the four characters. Actual value will depend in character encodings, but I am assuming 8 bit characters. Note there is no appended \0.

You can use the enums for normal comparison/assignment purposes. As with any enum the underlying type is integer.

I've used this technique in embedded systems many times to create 4 character 'names' that were human readable in hex dump/debugger contexts.

Steve Fallows
  • 6,274
  • 5
  • 47
  • 67
2

As already stated, those are integers declared using character constants.

When an integer is declared using a character constant of more than one character, it is sensitive to the byte order of the machine for which the constant was developed. As all the original Mac APIs were on PPC or earlier machines, they are backwards with respect to Intel Little-Endian machines.

If you are only building for Intel you can just reverse the order by hand.

If you are building a Universal binary you need to use a flipping function such as CFSwapInt32BigToHost.

Failure to correct those codes will leave you with code that could only work on PowerPC machines, regardless of the lack of compiler errors.

Andy Dent
  • 17,578
  • 6
  • 88
  • 115
0

That is an Apple extension to C, which It basically translates those enums to:

typedef enum {
    iTunesESrcLibrary = 'k'<<24 | 'L'<<16 | 'i'<<8 | 'b',
 ...
 }

EDIT: Sorry, apparently it's valid C. I've only seem them in Mac code, so wrongly assumed that it was Apple specific.

codelogic
  • 71,764
  • 9
  • 59
  • 54
  • It's not merely an Apple extension. I've used it in several C compilers and the ARM, sec 2.5.2 indicates it's valid C++. Don't have a C spec handy. But you're right about the value interpretation, typically. Officially it's implementation dependent. – Steve Fallows Feb 14 '09 at 01:26
  • Thanks, wasn't aware, gcc in Linux does warn about it though. – codelogic Feb 14 '09 at 01:34
  • @codelogic: I think the warning is due to the fact that the actual integer value isn't guaranteed to be consistend between compilers/systems. As long as you don't depend on the fact that 'abc' might have the value 6382179, you are safe as far as I know. – Christoph Feb 14 '09 at 01:39
  • The warning might be because the value is implementation dependent - hence is non-portable. – Steve Fallows Feb 14 '09 at 01:39
  • Yup, that's right. It's documented in the "-Wno-multichar" option in gcc. – codelogic Feb 14 '09 at 01:45
  • It is very definitely BYTE ORDER dependent - there are bugs still floating around on OS/X because of QuickTime constants. – Andy Dent Feb 14 '09 at 02:12
  • Why is this voted down? Just because codelogic doesn't mention the dependence on endianness? – Christoph Feb 14 '09 at 02:55