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: some array-related problems #2884
Comments
Comment author: administrator
You mean, unlike in the following C code? :-) void f(int x[]) More seriously: CamlIDL maps IDL arrays to C arrays when a
Yes, "unique" isn't applicable to arrays with a compile-time size.
Correct. I guess it should be possible to map them to C arrays when
That's a lot more problematic. For one thing, this is not valid ANSI C --
The way CamlIDL is currently set up makes it very hard to have
|
Comment author: administrator A follow-up to my previous reply:
A strong reason for doing this is that Caml bigarrays are designed so
|
Comment author: administrator Xavier Leroy Xavier.Leroy@inria.fr writes: First of all, I apologize for the very long delay.
For functions yes, but we are talking of structures. Obviously, C
OK.
Then we should prohibit using (int data[]) for now as non-supported And second, (int data[]) construct implemented as the data[1] array Hope to hear from you soon, |
Comment author: administrator Xavier Leroy Xavier.Leroy@inria.fr writes:
You are right. But it just means that [bigarray] int data[something or empty]; should be prohibited and the "bigarray" attribute is applicable only to Hope to hear from you soon, |
Original bug ID: 467
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: -for CamlIDL use https://github.com/xavierleroy/camlidl/issues
Bug description
applicable to arrays and should be ignored (array is not l-value and cannot
be equal to NULL). Currently incorrect C-code is generated:
typedef struct
{
int len;
[length_is(len),unique] char data[10];
} Array1;
|
V
typedef struct {
int len;
char data[10];
} Array1;
void camlidl_ml2c_array_Array1(value _v1, Array1 * _c2, camlidl_ctx _ctx)
{
value _v3;
mlsize_t _c4;
mlsize_t _c5;
value _v6;
if (_v1 == Val_int(0)) {
(_c2).data = NULL; / syntax error, data is not l-value! /
} else {
_v3 = Field(_v1, 0);
_c4 = Wosize_val(_v3);
if (_c4 != 10) invalid_argument("typedef Array1");
for (_c5 = 0; _c5 < 10; _c5++) {
_v6 = Field(_v3, _c5);
(_c2).data[_c5] = Int_val(_v6);
}
}
}
array) is always created:
typedef struct
{
int len;
[length_is(len)] int data[10];
} Array2;
typedef struct
{
int len;
[length_is(len),bigarray] int data[10];
} BigArray;
|
V
typedef struct
{
int len;
int data[10];
} Array2;
typedef struct {
int len;
int data; / why not data[10]? */
} BigArray;
them differently:
typedef struct
{
int len;
[size_is(len)] int data[];
} Array3;
|
V
camlidl:
typedef struct {
int len;
int *data;
} Array3;
midl:
typedef /* [public] / struct __MIDL___MIDL_itf_array_0000_0002
{
int len;
/ [length_is] */ int data[ 1 ];
} Array3;
I would prefer the MIDL way, because otherwise we cannot properly describe
C-structures where array (not pointer) is used, but its size is not
known. Of course, these arrays can only be used as [in] parameters, and
ML->C conversion functions should not be generated (if we need [out]
structure, we should use pointer, not array).
Hope to hear from you soon,
Dmitry
The text was updated successfully, but these errors were encountered: