Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000411OCamlCamlIDLpublic2001-06-27 16:592001-07-30 09:30
Reporteradministrator 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000411: camlidl and void
DescriptionFull_Name: Dmitry Bely
Version: 3.01, camlidl cvs 27.06.01
OS: Windows NT 4.0
Submission from: d009.p3.col.ru (195.210.132.9)


camlidl produces incorrect .ml[i] files, if type void* attribute is not
abstract:

[pvoid.idl]
typedef [ref] void* r_PVOID;
typedef [unique] void* u_PVOID;
typedef [ptr] void* p_PVOID;
typedef [abstract] void* a_PVOID;
typedef [ref] void** r_PPVOID;
[end of pvoid.idl]

gives

[pvoid.mli]
(* File generated from void.idl *)

type r_PVOID = void
and u_PVOID = void option
and p_PVOID = void Com.opaque
and a_PVOID
and r_pPVOID = void option
[end of pvoid.mli]

D:\Work\camlidl-test>ocamlc -c void.mli
File "void.mli", line 3, characters 15-19:
Unbound type constructor void

Some IDL declarations made no sense, and we probably should replace pointer
attrubutes with "abstract", generating an appropriate warning, but other(e.g.
"typedef [ref] void** PPVOID;") are correct -- we simply should generate the
correct code.

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0000039)
administrator (administrator)
2001-06-29 10:02

> camlidl produces incorrect .ml[i] files, if type void* attribute is not
> abstract:
>
> [pvoid.idl]
> typedef [ref] void* r_PVOID;
> typedef [unique] void* u_PVOID;
> typedef [ptr] void* p_PVOID;
> typedef [abstract] void* a_PVOID;
> typedef [ref] void** r_PPVOID;
> [end of pvoid.idl]

The MIDL spec states that "void" is only acceptable in three cases:
- as the return type of a function;
- to indicate an empty parameter list;
- in the construct [context_handle] void *

camlidl also supports [abstract] void *. I agree camlidl should check
for these cases and report an error instead of generating incorrect
Caml code. Still, none of the IDL declarations in your example makes
sense.

- Xavier Leroy

(0000040)
administrator (administrator)
2001-06-29 10:31

Behavior conforms to spec, but Microsoft-provided IDL files do not :-)
(0000041)
administrator (administrator)
2001-06-29 12:15

Xavier Leroy <Xavier.Leroy@inria.fr> writes:

> > camlidl produces incorrect .ml[i] files, if type void* attribute is not
> > abstract:
> >
> > [pvoid.idl]
> > typedef [ref] void* r_PVOID;
> > typedef [unique] void* u_PVOID;
> > typedef [ptr] void* p_PVOID;
> > typedef [abstract] void* a_PVOID;
> > typedef [ref] void** r_PPVOID;
> > [end of pvoid.idl]
>
> The MIDL spec states that "void" is only acceptable in three cases:
> - as the return type of a function;
> - to indicate an empty parameter list;
> - in the construct [context_handle] void *
>
> camlidl also supports [abstract] void *. I agree camlidl should check
> for these cases and report an error instead of generating incorrect
> Caml code. Still, none of the IDL declarations in your example makes
> sense.

They do, at least for MIDL :-( The following is from wtypes.idl (MSVC
distribution):

typedef void * PVOID, * LPVOID;
...
typedef struct _SECURITY_ATTRIBUTES {
    DWORD nLength;
    [size_is(nLength)] LPVOID lpSecurityDescriptor;
    BOOL bInheritHandle;
} SECURITY_ATTRIBUTES, *PSECURITY_ATTRIBUTES, *LPSECURITY_ATTRIBUTES;

Hope to hear from you soon,
Dmitry



- Issue History
Date Modified Username Field Change
2005-11-18 10:13 administrator New Issue


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker