MIDLC IDL Compiler

[Michael B Allen]

On Sun, 16 Jan 2005 14:54:26 +1100
Andrew Tridgell <tridge at osdl.org> wrote:

>  > Arrays attributed with [string] are treated specially by MIDLC as they
>  > are with MIDL. They *are* considered to be strings. When a [string]
>  > object is encountered it is passed to the {enc,dec}_ndr_string function
>  > to be converted between the server's encoding (e.g. UTF-16LE) and the
>  > locale dependant character encoding (e.g. UTF-8) of the calling
>  > process. I believe this is consistent with MIDL.
> 
> nope. [string] in MIDL means "array terminated by a zero element". You
> can use [string] on _any_ type, not just uint16. MIDL does no
> character conversion (see the NDR spec for full details).

That's not what I meant. I admit I worded that poorly. MIDL does not
perform the operations I speak of above. That is specific to MIDLC. But
the *effect* is that the user is using a "string" as they would with
MIDL stubs on windows. If you want to transfer a string and you don't
what to screw around with a header you use [string]. All I did was
add {enc,dec}_ndr_string functions to convert the encoding so it was
transparent to the user.

> wouldn't have enough information to get it right, as you also need to
> encode the termination type. Microsoft neglected to encode this in the
> IDL, but if you don't then you are going to hit major problems. Many

Huh? They have conformance information in the header. You don't need
the zero terminator.

>  > If the object in question is NOT really a string then the user would
>  > just have to decode it as a [size_is(size),length_is(length)] array
>  > explicitly and NOT use [string].
> 
> thats different on the wire, so it won't work

Why won't what work?

> add the extensions. The extensions are vital, but some of them change
> the basic structures in your compiler, so if you add them later you're
> just making a lot of work for yourself.

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.

>  > On the other hand, there are some things that I will never support. For
>  > example, PIDL just ignores the conformance DWORD before a structure
>  > with an embedded conformat array.
> 
> where do you get these claims about pidl from? We handle (and
> validate) the conformance value. Look for NDR_ERR_CONFORMANT_SIZE in
> our generated code. It's all over the place.

No. I'm not talking about a regular array.

If you have an embedded conformant array (not sure about the nomenclature
here) like sub_authority in:

    typedef struct {
        uint8_t revision;
        uint8_t sub_authority_count;
        uint8_t identifier_authority[6];
        [size_is(sub_authority_count)] uint32_t sub_authority[*];
    } sid_t;

On the wire there will be a 32 bits containing the size of the
sub_authority array (sub_authority_count) prefixed before the whole
structure. This is a special case because there's no place for conformance
information in the struct as sub_authority is embedded. Meaning you
wouldn't be able to take the sid object you use in your C code and
then pass it to NDR routines because there would be no place to hold
conformance info for sub_authority. According to the comment above the
typedef for dom_sid2 PIDL ignores this "esotaric" construct. I know it's
a pain but it's not just some "mistake".

>  > This would require that all Samba code that operates on dom_sid2 be
>  > converted together. Not sure if that's a big deal for you but we
>  > might as well get this stuff on the table now.
> 
> This is another example of where Microsoft goofed up, and we fixed
> it. Two different Microsoft programmers encoded the one structure, a
> dom_sid, in two different ways, making them incompatible on the wire. 
> 
> That means that Microsoft programmers have to deal with translating
> these two different structures bewteen each other in their code. They
> can't just use generic dom_sid handling functions everywhere.

Can you please provide examples of two calls that illustrate the different
encodings?

> how they work. As far as I can see you've just blindly assumed
> everything about pidl is worthless without even taking a look. Why? 

Could you imagine me trying to get PIDL to do Java? Seriously.

Also, I don't recall saying PIDL was worthless. I cited specific problems
for my objective. I said I needed a languange and application independant
solution. PIDL has a lot of stuff that is specific only to Samba.

Why didn't you use MIDL syntax for your IDL? You don't need to change
the *syntax* to implement your extensions.

  o You use [out] only string parameters. Illegal in MIDL.
  o You don't support embedded conformant arrays (e.g. dom_sid2 vs.
dom_sid).
  o You don't support [string] so making people convert to unistr is
"easyier"?
  o Pointer parameters are not [ref] by default.
  o No import (this would be problem for Java because it needs to know
    the interface from which the symbol came).
  o You've got custom attributes like [value] that does who knows what.

Why? What advantage does it give you to do this stuff?

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