MIDLC IDL Compiler

[Michael B Allen]

On Sun, 16 Jan 2005 17:36:17 +1100
Andrew Tridgell <tridge at osdl.org> wrote:

>  > Huh? They have conformance information in the header. You don't need
>  > the zero terminator.
> 
> It is common for the Microsoft server code to check the length to see
> if it exactly matches what they expect. So, for example, lsa mostly
> uses a non-terminated string. netlogon mostly uses terminated
> strings. Microsoft cope with this by forcing people who program each
> interface to know which convention is used. For example, see this:

Well a 'unicode_string' is not [string] wchar_t *. But both have conformance
information. If the conformance information is wrong then that's a different
issue.

> That is incredibly error prone. We cope with this using a flag
> extension on strings to indicate the termination. We also check

I agree all the different strings being used sucks but [string]s are easy.
Why break them? If I add an extension to assist the developer by unifying
string handling it will not involve dumping [string] support.

>  > Instead of speaking about vague concepts can you provide a specific
>  > example of a "vital" extension? Please tell me what call or provide an
>  > IDL fragment that illustrates clearly that only a compiler extension
>  > could support reasonably.
> 
> A good example is the string handling above. Others include the
> relative pointers needed for spoolss, and for coping with security
> descriptors sanely. We also have extensions for forcing little-endian
> (needed to encode epmapper.idl and for parts of DCOM) and for forcing
> no alignment (needed for epmapper and the krb5 PAC).

Well aside from the string stuff this just isn't NDR. Do you want to do SMBs
with your "IDL compiler" too? That's just a *little* outside the scope of my
project right now.

> Then we have extensions to make life easier for programmers, like
> value() for automatically filling in well-known values, and the
> various print extensions for auto-generating debugging functions that
> can print complex structures.

Ok so let's look at the value() attribute. In lsa you have:

    typedef struct {
        [value(2*strlen_m(r->string))] uint16 length; 
        [value(r->length)] uint16 size;
        unistr_noterm *string;
    } lsa_String;

This is a good example because we've touched on strings a bit. So you use
this like:

    typedef struct {
        lsa_String name;
        dom_sid2 *sid;
    } lsa_DomainInfo;

So you have a non-generic string type (ditto in samr and winreg) with Samba
specific C expressions inside custom attributes. Whereas if you did this the
pure MIDL way you'd have:

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

    typedef struct {
        unicode_string name;
        sid_t *sid;
    } lsa_DomainInfo;

I don't see what's really bad about this. If you have functions to convert
to/from C strings it's just not *that* bad..

But ok, it's is kinda ugly (never claimed MS stuff was elegant) so we could
do:

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

    typedef struct {
        unicode_string name;
        sid_t *sid;
    } lsa_DomainInfo;

Now pass the type of string to the {enc,dec}_ndr_string leaf routine. That
allows you to handle the odd double conformance info directly. The C
expressions are gone. They're in the ndr code where they belong. No
extension necessary.

> I didn't use a conformant array for dom_sid2 as I wanted it to be type
> compatible with the ones that can't be represented in that way.
<snip>
>  >   o You don't support embedded conformant arrays (e.g. dom_sid2 vs.
>  > dom_sid).
> 
> yes, we do support them

Ok. I assumed that because you didn't use the "correct" IDL representation
that you didn't support them. My mistake.

>  > Could you imagine me trying to get PIDL to do Java? Seriously.
> 
> I didn't propose you use pidl, but I proposed you at least read it so
> you don't make the same mistakes we made.

I don't accept that not implementing extensions is a "mistake". Why do you
think I should somehow know in advance that I have to do some kind of
extensions anyway?

So far MIDLC does exactly what it's designed to do. What "mistakes" have I
made?

>  >   o Pointer parameters are not [ref] by default.
> 
> we support the midl syntax for [ref] pointers. We also support an
> alternative syntax that can be neater in some cases.

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.

Mike

-- 
Greedo shoots first? Not in my Star Wars.