Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000406OCamlCamlIDLpublic2001-06-27 11:532001-07-30 09:30
Reporteradministrator 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000406: camlidl and int64 attribute
DescriptionFull_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...


TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0000030)
administrator (administrator)
2001-06-29 10:28

> 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

(0000031)
administrator (administrator)
2001-06-29 13:29

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] <any signed integer type> 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


(0000032)
administrator (administrator)
2001-06-29 15:21

Added support for __int64 and "hyper int" and "long long int". XL, 2001-06-29
(0000033)
administrator (administrator)
2001-06-29 16:31

> 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


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


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker