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 does not accept 'unsigned' as an alias of 'unsigned int' #5570

Closed
vicuna opened this issue Apr 1, 2012 · 1 comment
Closed

CamlIDL does not accept 'unsigned' as an alias of 'unsigned int' #5570

vicuna opened this issue Apr 1, 2012 · 1 comment

Comments

@vicuna
Copy link

vicuna commented Apr 1, 2012

Original bug ID: 5570
Reporter: @jberdine
Status: closed (set by @xavierleroy on 2012-04-03T14:13:53Z)
Resolution: suspended
Priority: normal
Severity: minor
Platform: x86_64
OS: Windows
OS Version: 7
Category: -for CamlIDL use https://github.com/xavierleroy/camlidl/issues

Bug description

I am unsure whether it is guaranteed by the C standard, but 'unsigned' is sometimes used as an alias for 'unsigned int'. See for instance http://msdn.microsoft.com/en-us/library/a86zba5c.aspx.

It does not seem to be straightforward to work around this when using CamlIDL to bind to an existing C library that uses these type aliases by generating .idl files from the existing .h files. CamlIDL itself rejects 'typedef unsigned int unsigned' and attempting '#define unsigned unsigned int' produces erroneous results for instances of e.g. 'unsigned long'. This seems to leave very complex sed scripts or reparsing the header files.

Steps to reproduce

$ cat foo.h
void f(unsigned);

$ cat foo.c
#include "foo.h"

void main(void) {
unsigned x = 0;
f(x);
}

void f(unsigned x) {
}

$ cl /nologo foo.c
foo.c

$ camlidl foo.h
foo.h
File foo.h, line 1, column 15: syntax error

@vicuna
Copy link
Author

vicuna commented Apr 3, 2012

Comment author: @xavierleroy

CamlIDL now lives its own life at http://forge.ocamlcore.org/projects/camlidl/ with its own bug tracker. It could use new developers to breathe some life into it. The issue you mention sounds like it would be easy to address by a small change to the parser.

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