IDL [string] attribute (was svn commit: samba r11105 ...)

Jelmer Vernooij jelmer at
Tue Oct 18 16:41:41 GMT 2005

Hash: SHA1

Michael B Allen wrote:

> On Mon, 17 Oct 2005 22:36:36 +0200 Jelmer Vernooij
> <jelmer at> wrote:
>>> Also, about the type 'uint16' - for midlc I was going to
>>> represent [string] wchar_t *str with the locale dependant
>>> codeset internally (e.g. UTF-8) and UTF-16LE as the wire
>>> encoding. This allows existing IDL written for Windows to be
>>> used elsewhere (e.g. UNIX) as-is. Note that this means that in
>>> the generated headers and stubs, the 'wchar_t' type must be
>>> converted to a generic character type to be defined by the user
>>> (e.g. if locale charset is UTF-8 then typedef unsigned char
>>> char_t) because 'wchar_t' is a standard C library type.
>> I'm not a big fan of assuming codesets depending on the data
>> type. For
> Just to infer the default encoding? That's no big deal. If it's
> wchar_t and there's no codeset attrbute, you make the codeset
> UTF-16LE. And if it's char without a codeset attr then make it DOS.
> You should have a default so you might as well exercise the
> Principle of Least Surprise.

I'd prefer to have the default be an unconverted string instead, so
conversion isn't mandatory. It forces users to think about what
they're doing. We already have [charset(UTF16)] specified everywhere
in our IDL.

> But you still have to edit IDL imported from a Windows project.
> Even if it is just two lines, it's just not necessary. Infer the
> default encoding from the IDL type.

Only if you want your IDL compiler to do conversion for you, which
doesn't always have to be the case.

> I can't see these defines really working anyway. What about 'const
> wchar_t *' or 'struct { unsigned char flags; ...'? Even if they
> were typedefs I think you'll have problems.

Right, that's true. Perhaps we could add a --automatic-conversion flag
to our IDL compilers instead that provides the behaviour you describe?


Version: GnuPG v1.4.2 (GNU/Linux)


More information about the samba-technical mailing list