Re: [Swig-user] Apple's 4-char enum?

[William S F. <ws...@fu...>]

On 20/09/13 23:05, Eric Wing wrote:
> On 9/19/13, Beinan Li <bl...@au...> wrote:
>> Thanks. This must be an Apple compiler-specific thing. It is widely used in
>> Mac/iOS headers.
>> which gets translated into a 4-byte integer fine with llvm but SWIG just
>> doesn't know it.
>
>
> This is called FourCC and it is a perfectly valid C/C++ technique.
> http://en.wikipedia.org/wiki/FourCC
>
> This sounds like a SWIG bug that should be fixed in my opinion. You
> are right, it is widely used in some lower level Apple APIs, such as
> Core Audio. It is also used in Microsoft DirectX if I recall.

These multi-character constants are in the C99 standard - "An integer 
character constant is a sequence of one or more multibyte characters 
enclosed in single-quotes".

SWIG aims to support the standard and in this case SWIG does actually 
support them seamlessly in target languages other than C#. The following 
is taken from the SWIG manual 
http://www.swig.org/Doc2.0/CSharp.html#CSharp_differences_java:


"The default enum wrapping approach is proper C# enums, not typesafe 
enums. Note that %csconst(0) will be ignored when wrapping C/C++ enums 
with proper C# enums. This is because C# enum items must be initialised 
from a compile time constant. If an enum item has an initialiser and the 
initialiser doesn't compile as C# code, then the %csconstvalue directive 
must be used as %csconst(0) will have no effect. If it was used, it 
would generate an illegal runtime initialisation via a PInvoke call."

So you can get this working by manually providing the value with 
something like:

%csconstvalue(0x616d6269) kAudioSessionCategory_AmbientSound;

to generate C# code:

   kAudioSessionCategory_AmbientSound = 0x616d6269

I don't know if 0x616d6269 really is the correct interpretation for 
'ambi' as how these are interpreted is implementation defined ... the 
following is from the C99 standard in Section 6.4.4.4 (Character 
constants) says:

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

The implementation defined problem for SWIG is avoided in most of the 
language modules by just obtaining the value from C compiled code. For 
the C# wrappers, a C# compile time constant is required and as far as I 
can see this is an insurmountable problem for SWIG to solve without 
manual intervention with %csconstvalue. This is for two reasons: 1) C# 
enums requires a compile time constant and C# does not support multi 
byte character constants. 2) There is no standard way to convert multi 
byte character constants to plain integers.

If someone wants to investigate what the implementation defined 
behaviour is on a few commonly used systems and then provide a patch for 
a new %feature to automatically convert multi byte character constants 
into an integer value, based on one more implementation behaviours, then 
I'll commit the patch for inclusion in future versions of SWIG. An 
assumed behaviour, say for Microsoft Windows Visual Studio, could also 
be turned on by default. Perhaps all the common C# systems use the same 
implementation?

William