MIDLC IDL Compiler

[Andrew Tridgell]

Mike,

 >     typedef struct {
 >         uint16_t length; 
 >         uint16_t maximum_length;
 >         [length_is(length / 2),size_is(maximum_length / 2)] uint16_t
 > *buffer;
 >     } unicode_string;

the problem is, how do you initialise "length" and "maximum_length" ?
They need to be the length in utf16 format. That means the application
code needs to know how to find the utf16 length from a char*, and
manually initialise all instances of these. 

We didn't do value() initially in pidl, and everyone on the team made
mistakes. Some assumed things like 2*strlen(), because it worked for
them. I added value() to address a commonly made error in coding to
our generated API. It ensured that all the knowledge was stored in one
place, nobody could make errors, and the knowledge is auto-validated
when we received packets from MS.

I'd be happy to look at a different solution, but it has to keep the
burden away from the programmer.

 >     #ifdef EXT_UNIFIED_STRINGS
 >     typedef [string(STR_LSA_STRING)] wchar_t unicode_string;
 >     #endif

ahh, I think you may have assumed that "unistr" is a type in
pidl. It's not. We run our IDL thought cpp first, and define unistr
like this in idl_types.h:

  #define unistr [flag(STR_SIZE4|STR_LEN4)]  string

so the compiler doesn't know anything special about the "string" type,
it just calls the standard pattern for any external type, and our NDR
library knows what to do for this magic type, including looking at the
additional flag() settings. Maybe your solution won't be as far from
what pidl does as you think?

 > But you have [ref] in parameters that are pointers. Why? All parameters that
 > are pointers are *always* [ref] unless explicitly set [unique] (regardless
 > of what pointer_default is). Wouldn't that be "neater"? Also, does this mean
 > your pointer parameters are [unique] by default? This is a really small
 > thing but, like depends(), it's just different for no reason.

The constraints on pointers in MIDL come from the way that MIDL
generates function interfaces. I chose to use an in/out structure
split for the interface, and it has proved to be a real benefit. Once
you do that then the constraints naturally go away. We could
artifically add those constraints, but there seems little point in
resticting people who write IDL to follow such restrictions.

A basic difference between our approaches is that we don't intend our
IDL to be compilable under MIDL. We'd have to drop too many things
that make life easier for us. You use MIDL to validate your IDL, which
means you have to make it compatible. Instead, we instead write
smbtorture test suites to try every function against both a Samba4
server and a Windows server.

As long as you want to keep your IDL compilable with MIDL then I
suspect our two approaches won't be compatible, so we'll continue with
our efforts on pidl, and add the extra features we need as we hit
them.

Cheers, Tridge