Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

camlidl and void #2815

Closed
vicuna opened this issue Jun 27, 2001 · 3 comments
Closed

camlidl and void #2815

vicuna opened this issue Jun 27, 2001 · 3 comments

Comments

@vicuna
Copy link

vicuna commented Jun 27, 2001

Original bug ID: 411
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: -for CamlIDL use https://github.com/xavierleroy/camlidl/issues

Bug description

Full_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.

@vicuna
Copy link
Author

vicuna commented Jun 29, 2001

Comment author: administrator

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

@vicuna
Copy link
Author

vicuna commented Jun 29, 2001

Comment author: administrator

Behavior conforms to spec, but Microsoft-provided IDL files do not :-)

@vicuna
Copy link
Author

vicuna commented Jun 29, 2001

Comment author: administrator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant