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 problems #2773

Closed
vicuna opened this issue Jun 2, 2001 · 2 comments
Closed

camlidl problems #2773

vicuna opened this issue Jun 2, 2001 · 2 comments

Comments

@vicuna
Copy link

vicuna commented Jun 2, 2001

Original bug ID: 374
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 1.01
OS: Windows NT 4.0
Submission from: d204.p3.col.ru (195.210.132.204)

  1. For compatibility with Microsoft IDL (and maybe other IDL compilers) it would
    be nice to emit '\n' into the target file after each cpp_quote/quote statement.
    It will let the following construct work correctly:

cpp_quote("#define FAR _far")
cpp_quote("#define PASCAL _pascal")
cpp_quote("#define CDECL _cdecl")

(currently all these #define statements are merged into one line)

  1. [string] attribute (and maybe others) is handled wrong for typedefs:

typedef [string] char* PCHAR1; /* OK */

but

typedef char CHAR;
typedef [string] CHAR* PCHAR2; /* Warning: attribute `string' unknown, malformed
or not applicable here, ignored. */

midl handles this correctly and intensively use such constructs in its .idl
files.

  1. "const" is not allowed in type-spec declarators. So the following does not
    pass camlidl:

void f( const char* c ); /* syntax error */
typedef [string] const char LPCSTR; / syntax error */

Yes, this behaviour conforms to Camlidl manual, but midl intensively use this
feature, and it seems to be natural for IDL language.

  1. In case of syntax error Camlidl sometimes points at the wrong place
    (sometimes far away from the real place if .idl file is big enough). Here is an
    example:

--- test.idl
// line 0, pos 0
typedef unsigned short WORD;
typedef unsigned int UINT;
typedef int INT;
typedef long BOOL;
typedef long LONG;
typedef UINT WPARAM;
typedef unsigned long DWORD;
typedef LONG LPARAM;
typedef LONG LRESULT;
typedef void * HANDLE;
typedef HANDLE HDWP;
#define DECLARE_HANDLE(name) typedef void * name

DECLARE_HANDLE(HMODULE);
DECLARE_HANDLE(HINSTANCE);
DECLARE_HANDLE(HRGN);
DECLARE_HANDLE(HTASK);
DECLARE_HANDLE(HKEY);

DECLARE_HANDLE(HDESK);

DECLARE_HANDLE(HMF);
DECLARE_HANDLE(HEMF);

DECLARE_HANDLE(HPEN);
DECLARE_HANDLE(HRSRC);
DECLARE_HANDLE(HSTR);
DECLARE_HANDLE(HWINSTA);
DECLARE_HANDLE(HKL);
DECLARE_HANDLE(HGDIOBJ);
// (_) <- line 31, pos 11
typedef [string] const char *LPSTR;
--- end of test.idl

produces

test.idl
File test.idl, line 31, character 11: syntax error

although the real position is line 32, char 17 ("const" problem, discussed
above)

@vicuna
Copy link
Author

vicuna commented Jun 18, 2001

Comment author: administrator

  1. For compatibility with Microsoft IDL (and maybe other IDL
    compilers) it would be nice to emit '\n' into the target file after
    each cpp_quote/quote statement.

Good point. Done.

  1. [string] attribute (and maybe others) is handled wrong for typedefs:

Fixed.

  1. "const" is not allowed in type-spec declarators. So the following does not
    pass camlidl:

It seems that "const" in types was only recently added to the COM IDL
specification. I patched CamlIDL to support it, although it's a bit
of a hack; in particular there is a weird parsing ambiguity between
const int x = 1 /* a constant declaration /
and
const int f(); /
a function declaration */
but this isn't too bad since the latter can also be written
int const f();

  1. In case of syntax error Camlidl sometimes points at the wrong
    place (sometimes far away from the real place if .idl file is big
    enough). Here is an example:

That's a general problem with Yacc parsers: they can shift quite a lot
of text before getting stuck and reporting an error. So, I haven't
addressed this issue.

If you wish to test the working sources for CamlIDL, which should fix
all the issues you reported, you can get them using anonymous CVS from
camlcvs.inria.fr. (See http://camlcvs.inria.fr/) I'll probably make
a public release within one month.

All the best,

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Jun 21, 2001

Comment author: administrator

Fixed 2001-06-18 by XL.

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