MIDLC IDL Compiler
Michael B Allen
mba2000 at ioplex.com
Sun Jan 16 05:41:50 GMT 2005
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.
More information about the samba-technical
mailing list