Re: MIDL language features / tests

Hi Albert,

I'm CCing the jcifs list since that was the point of contact for midlc.

What features midlc supports are MIDL compatible but it does not support
all of the features of MIDL. So most of the issues you list are not
supported. Also, due to a change in job status I'm afraid that, aside
form maintaining jCIFS, I will probably not be working on OSS projects
much. If anyone feels like mildc is something they would like to use,
I recommend that they creat an Open Source project for midlc somewhere
so that others can contibute and keep the project going.

More notes below.

On Thu, 03 Nov 2005 14:48:12 -0500
Albert Cahalan <acahalan@xxxxxxxxxx> wrote:

> This is a list of problems I found in somebody else's
> MIDL compiler. You can use this list for testing.
> 
> ---------------------------------------------------------------------
> 
> The ms_union keyword is critical for dealing with  Microsoft APIs.
> Note that the keyword can be used in two different  contexts,
> and also as a command-line option.
> 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/midl/midl/_ms_union.asp
>  

I don't know what this really looks like on the wire do I'm not sure
how difficult it would be to support. Probably not too bad though.

> -----------------------------------------------------------------------
> 
> The IDL compiler needs to define __midl.
> Set it to 500 or more if async_uuid is supported.
> Set it to 502 or more if __int3264 is supported.
> 
> Obviously, 502 or above would be best.

Adding defines and new attributes is trival. Midlc doesn't do
anything with COM yet and it doesn't do anything with I/O so supporting
async_uuid is up to the transport. The NDR functions are fully reentrant
however. Supporting __int3264 would be trivial.

> -------------------------------------------------------------------------------
> 
> The IDL compiler needs to define MIDL_PASS.

Trivial. Just add it to the macros hashmap in midlc.c. Actually you
could work around this with the existing version by using the -D flag.

> -------------------------------------------------------------------------------
> 
> The midl_pragma keyword is needed. Probably you can
> implement it well  enough by just ignoring everything
> until the end of the line. Usage  looks like this:
> 
> midl_pragma warning(disable:2466 2467)

This is less trivial because to do it properly requires modifying the
parser which is dangerous. I don't think it would be TOO bad, but
you can't just "ignore everything until the end of the line". The parser
doesn't really work like that. I would probably create a separate state
for midl_pragma and then another for warning and collect and discard
everything between the '(' and ')'.

> ----------------------------------------------------------------------------
> 
> #pragma should be passed through to the C compiler.
> You can make an  exception for any #pragma that starts
> with midl_ though.

This is less trivial since pragmas can be interpreted by cpp, midlc,
or the compiler. At least I'm not really sure what's involved.

> ------------------------------------------------------------------------
> 
> Microsoft accepts this:
> 
> typedef unsigned short us;
> struct foo {
> us bar;
> char baz[14];
> };

I don't see anything exceptional about this code. It should work as is now.

> ---------------------------------------------------------------------------------------
> 
> Be sure to accept more than one interface per IDL file,
> and some basic usage of ACF in the IDL files.

I don't recall if midlc can handle more than one interface per IDL file. I
didn't think such a thing was possible. Midlc does not support ACF at
all but I don't think adding such support would be terribly difficult. Of
course each ACF directive requires additional thought.

> ---------------------------------------------------------------------------------
> 
> Feature:  range(0,50)
> Info: 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/midl/midl/range.asp
>  

I beleive midlc supports this but the actual checks are not emitted in
the marshalling routines. In fact there are very few checks of any kind
at this point only because I wanted the code to be easier to read while
the logic is fleshed out.

> --------------------------------------------------------------------------------
> 
> Feature: size_is(,*foo)
> Info: 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/midl/midl/size_is.asp
>  

Double subsript arrays are not supported. The code is consciencious of
such things but it was never tested and I doubt it works. I think simple
C expressions like '*foo' are computed correctly however (e.g. single
dimension size_is(*foo) should work).

> -----------------------------------------------------------------------------
> 
> Use of [in,unique] with a string typedef is allowed.
> Microsoft accepts syntax like this:
> 
> typedef [string] unsigned short * uss;
> some function(
> [in, unique] uss foo,   // right here
> [in, range(0,42)] long bar
> );

Midlc fully supports attribute inheritence. The member foo would be
[in,unique,string]. But I think [string] handling in C is broken. It works
in the Java stubs but something broke when I did the samba stub revision
(Samba doesn't really use [string]).

> --------------------------------------------------------------------------
> 
> It's best to work like lex and yacc. Trying to run the C compiler
> is wrong. Being or using a thread library is probably wrong.

Midlc does not use lex or yacc. I didn't have the patience and I don't
see a tremendous amount of value in those tools. It does not try to run
the C compiler but of course it runs the C preprocessor. And of course
it does not use thread libraries as midlc only emits stubs and does not
supply a runtime for any transport.

Mike