[Caml-list] bug report: camlidl

[Caml-list] bug report: camlidl

[Dmitry Bely]

Excuse me if I'm posting this to the wrong place -- I am new to the caml
community.

Here is the bug description. Let's consider the following example:

--- test.idl ---
[
    object
]
interface IX: IUnknown
{
    HRESULT something();
}

[
    object,
    pointer_default(ref)
]
interface IY: IUnknown
{
    HRESULT_bool getBool();
    HRESULT_bool getIX( [out] IX **p );
}
--- end of test.idl ---

$ camlidl -header test.idl
test.idl

$ ocamlc -ccopt /Zi -c -ccopt test.c

test.c
test.h(43) : error C2061: syntax error : identifier 'HRESULT_bool'
...

$ ocamlc -ccopt /Zi -c -ccopt /DHRESULT_bool=HRESULT test.c

test.c
test.c(76) : warning C4047: 'function' : 'long ' differs in levels of indirection from 'long *'
test.c(76) : warning C4024: 'camlidl_c2ml_Com_HRESULT_bool' : different types for formal and actual parameter 1
test.c(76) : warning C4020: 'camlidl_c2ml_Com_HRESULT_bool' : too many actual parameters
test.c(100) : warning C4047: 'function' : 'long ' differs in levels of indirection from 'long *'
test.c(100) : warning C4024: 'camlidl_c2ml_Com_HRESULT_bool' : different types for formal and actual parameter 1
test.c(100) : warning C4020: 'camlidl_c2ml_Com_HRESULT_bool' : too many actual parameters
test.c(126) : warning C4020: 'camlidl_ml2c_Com_HRESULT_bool' : too many actual parameters
test.c(147) : warning C4020: 'camlidl_ml2c_Com_HRESULT_bool' : too many actual parameters

So the following bugs are obvious:

1. HRESULT_bool (and HRESULT_int) definition is missed in camlidlruntime.h
(or camlidl compiler should always generate code with HRESULT instead of them)

2. The way compiler uses camlidl_c2ml_Com_HRESULT_bool() and
camlidl_ml2c_Com_HRESULT_bool() does not conform to their
definition. Specifically, the generated code implies some context structure
parameter while camlidl_*_Com_HRESULT_bool() definitions have no idea about
it.

Of course, I can easily fix the first problem myself, but in the later case
I have to give up -- ocaml internals are still beyond my comprehension.

If someone is capable to fix that, I'd be very obliged -- it's currently
the real showstopper for me :-(

Hope to hear from you soon,
Dmitry


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] bug report: camlidl

[Dmitry Bely]

One more thought:

--- test.idl ---
[
    object
]
interface IX: IUnknown
{
    HRESULT getValue( [out] int* value );
}
--- test.idl ---

leads to the problem due to

int *value; /*out*/

in the generated code (value is a typedef). The same is true for other
camlidl internal types. I think that mangling parameter names by the
compiler (something like _value_parameter of so) could be the good
solution.

And the last problem:
why the web search in the caml mailing list archive does not work? :-)

Hope to hear from you soon,
Dmitry


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] bug report: camlidl

[Alan Schmitt]

>And the last problem:
>why the web search in the caml mailing list archive does not work? :-)

Could you be more precise, it seems to work here ...

Alan

--
The hacker: someone who figured things out and made something cool happen.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] bug report: camlidl

[Dmitry Bely]

Alan Schmitt <alan.schmitt@inria.fr> writes:

> >And the last problem:
> >why the web search in the caml mailing list archive does not work? :-)
> 
> Could you be more precise, it seems to work here ...

It failed to find anything; every request (that was guaranteed to give
non-empty result) just returned "Found 0 matches in 0 files". But now it
really works. Very strange ...

Hope to hear from you soon,
Dmitry


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr