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 int64 attribute #2810

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

camlidl and int64 attribute #2810

vicuna opened this issue Jun 27, 2001 · 4 comments

Comments

@vicuna
Copy link

vicuna commented Jun 27, 2001

Original bug ID: 406
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
Submission from: d009.p3.col.ru (195.210.132.9)

int64 attribute is handled wrong (and also int32 on 64-bit platforms). Example:

[test.idl]
typedef [int64] unsigned int DWORDLONG;
[end of test.idl]

is compiled to

[test.h]
...
typedef unsigned int DWORDLONG; // Error!
[end of test.h]

and

[test.c]
...
void camlidl_ml2c_test_DWORDLONG(value _v1, DWORDLONG * _c2, camlidl_ctx _ctx)
{
(*_c2) = Int64_val(_v1);
}

value camlidl_c2ml_test_DWORDLONG(DWORDLONG * _c2, camlidl_ctx _ctx)
{
value _v1;
_v1 = copy_int64((*_c2));
return _v1;
}
[end of test.c]

which obviously is not acceptable. We should generate

typedef uint64 DWORDLONG; // uint64 is ocaml's typedef

BTW, MIDL uses

typedef unsigned __int64 DWORDLONG;

I know, that's platform specific, but treating MSVC's __int64 and gcc's (long
long) as ([int64] int) would be nice. Of course I do not insist on that...

@vicuna
Copy link
Author

vicuna commented Jun 29, 2001

Comment author: administrator

int64 attribute is handled wrong (and also int32 on 64-bit
platforms). Example:

[test.idl]
typedef [int64] unsigned int DWORDLONG;
[end of test.idl]

is compiled to

[test.h]
...
typedef unsigned int DWORDLONG; // Error!
[end of test.h]

Sorry for playing the spec lawyer once more, but the intent of the modifiers
[int32], [int64], etc, is to specify the Caml type corresponding to
the IDL type; they don't impact the C type.

On an Alpha for instance (where sizeof(long) == 8), it makes perfect
sense to define
typedef [int64] long TY;

Still, you're pointing at an embarrassing shortcoming of Camlidl:
there is no way to specify a 64-bit C integer type. The MIDL spec
provides two syntaxes for this, namely "__int64" and "hyper int",
and I agree with you that "long long int" should also be allowed.
I'll implement this at some point.

Thanks for all your feedback; you're the first to really stress test
Camlidl, and that's very useful.

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Jun 29, 2001

Comment author: administrator

Xavier Leroy Xavier.Leroy@inria.fr writes:

Sorry for playing the spec lawyer once more, but the intent of the modifiers
[int32], [int64], etc, is to specify the Caml type corresponding to
the IDL type; they don't impact the C type.

On an Alpha for instance (where sizeof(long) == 8), it makes perfect
sense to define
typedef [int64] long TY;

but if you define

typedef [int64] int TY;

and compile it on MSBLSB 32-bit machine (or [int32] int on 64-bit MSBLSB
one), you will get runtime error because in the resulting

typedef int TY;
value camlidl_c2ml_int64_TY(TY * _c2, camlidl_ctx _ctx)
{
value _v1;
_v1 = copy_int64((*_c2));
return _v1;
}

copy_int64() is defined as

value copy_int64 (int64); /* defined in [ints.c] */

and expects 64-bit integer, not 32-bit. IMHO, we should at least generate a
warning in such case.

Still, you're pointing at an embarrassing shortcoming of Camlidl:
there is no way to specify a 64-bit C integer type.

Why simply do no translate

typedef [int64] TY;

to

typedef int64 TY; // int64 defined in ocaml's config.h

(similarly for unsigned)?

The MIDL spec
provides two syntaxes for this, namely "__int64" and "hyper int",
and I agree with you that "long long int" should also be allowed.
I'll implement this at some point.

That would be nice, although right now I can live without it -- MIDL 1.0
also does not know about __int64 and all Microsoft's idl files contain
something like

...
//
// __int64 is only supported by 2.0 and later midl.
// __midl is set by the 2.0 midl and not by 1.0 midl.
//

cpp_quote("#ifndef ULONGLONG")

#if (defined(__midl))
typedef __int64 LONGLONG;
typedef unsigned __int64 ULONGLONG;
#else
typedef double LONGLONG;
typedef double ULONGLONG;
#endif

Thanks for all your feedback; you're the first to really stress test
Camlidl, and that's very useful.

I have also made some changes to make camlidl COM part work under
mingw/cygwin -- some times ago I wrote to caml@inria.fr, that I was able to
get mingw-based native Win32 port of ocaml compiler, and asked if anybody
interested in that ...

Hope to hear from you soon,
Dmitry

@vicuna
Copy link
Author

vicuna commented Jun 29, 2001

Comment author: administrator

Added support for __int64 and "hyper int" and "long long int". XL, 2001-06-29

@vicuna
Copy link
Author

vicuna commented Jun 29, 2001

Comment author: administrator

and compile it on MSBLSB 32-bit machine (or [int32] int on 64-bit MSBLSB
one), you will get runtime error because in the resulting

typedef int TY;
value camlidl_c2ml_int64_TY(TY * _c2, camlidl_ctx _ctx)
{
value _v1;
_v1 = copy_int64((*_c2));
return _v1;
}

copy_int64() is defined as

value copy_int64 (int64); /* defined in [ints.c] */

and expects 64-bit integer, not 32-bit. IMHO, we should at least generate a
warning in such case.

I don't follow you here. TY and int64 are both integral types, and
the C compiler will convert silently from TY to int64 at the call site
for copy_int64.

Still, I just added the "__int64", "hyper int" and "long long" types
to Camlidl. The CVS archive contains the changes.

I have also made some changes to make camlidl COM part work under
mingw/cygwin -- some times ago I wrote to caml@inria.fr, that I was able to
get mingw-based native Win32 port of ocaml compiler, and asked if anybody
interested in that ...

Right. Sorry for not having responded earlier. I played with mingw a
while ago but stopped when I discovered that it does not support many
Win32 functions, in particular the COM stuff... Also, our user base
seems split between those who want a Unix-like environment under
Windows, and therefore favor the full Cygwin environment, and those
who say that they must use Microsoft tools because their customers and
coworkers just laugh at Cygwin. Mingw doesn't seem to fit this picture,
and the last thing I'd want is having to support a third Windows
version of Caml :-)

  • Xavier Leroy

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