One of the areas of pidl I am currently to improve is compatibily with other IDL compilers, so that exchanging IDL files becomes easier. We currently have extensions in pidl (with good reason!), that are unfortunately not supported by other compilers. My aim is therefore to not make support for these extensions a requirement for being able to load IDL files that use them. The easiest way to support something like that is by removing a few of the pidl-specific attributes before compiling with another compiler.

A recent change I made to pidl was the addition of support for the [string] attribute that is traditionally used in DCE/RPC IDL to make strings (which are nothing more then zero-terminated arrays, as far as NDR is concerned). For example, a string can be declared as follows in traditional IDL:

1

[string]  wchar *bla;

pidl previously had it’s own way of handling strings (a “string” type with special flags to indicate whether it was in ASCII, unicode, fixed-length, etc) which had the advantage that it would take care of handling the conversion between whatever character encoding was used on the wire and whatever one was used by Samba internally. The string specified above would look something like this:

1

[flag(STR_SIZE4|STR_LEN4)] string *bla;

In order to support [string] and also do on-the-fly character set conversions, I also added a new [charset()] attribute that tells Samba from what character set to convert. The string above would now look something like this:

1

[string,charset(UTF16)] wchar *bla;

One of the other extensions that needs to be a bit more optional is the [subcontext] attribute. This attribute is currently used for interpreting various generic data blobs that are send using DCE/RPC and traditionally interpreted by another layer in Windows. Subcontexts allow us to merge these two layers in Samba. For example the following code on windows:

1
2

uint32 size;
[size_is(size)] uint8 data[];

(data would then by casted to a FOO_BAR on a higher level), would look like this in Samba at the moment:

1
2

uint32 size;
[subcontext(4)] FOO_BAR data;

The problem here is that [subcontext()] is not very flexible. It’s argument is not very intuitive to use, and there are two other attributes available that change its behaviour.

I’d like to, in the future, replace subcontext with something like this:

1
2

uint32 size;
[size_is(size),replace(FOO_BAR)] uint8 data[];

Pidl would then call the push / pull / print functions of FOO_BAR after processing data[]. The uint8 array would only be declared locally in the pull / push / print function and “FOO_BAR data;” would appear in the public structures.

I’m not yet clear on what the semantics of the pull / print / push functions for FOO_BAR would be. Requiring names like ndr_{pull,push,print}_FOOBAR and the standard NDR arguments would certainly make sense, but it would also be great if we could support custom non-NDR subcontexts more easily (such as TDR-generated or hand-written ones). A possible solution would be allowing something like [replace(FOO_BAR,tdr)], maybe having the prefix default to “ndr”?