You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 448 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: camlidl current cvs
OS: Windows NT 4.0
The following IDL definition
typedef struct {
int imageLen;
[size_is(len),unique,bigarray] char *imageData;
} Image;
produces
type struct_1 = (char, Bigarray.int8_unsigned_elt, Bigarray.c_layout) Bigarray.Array1.t
and image = struct_1
i.e. silently ignores "unique" attribute without warning/error
message. IMHO that's not good. I'd like it to produce
type struct_1 = (char, Bigarray.int8_unsigned_elt, Bigarray.c_layout) Bigarray.Array1.t option
and someData = struct_1
as well as
typedef struct {
int imageLen;
[size_is(len),unique] char *imageData;
} Image
produces
type struct_1 = char array option
and image = struct_1
Why I need it:
There is a library that uses similar structure as an image
descriptor. "imageData" is allocated/deallocated by special library
functions, and is linked with some internal data, so "bigarray" is the only
option to access/modify it from caml "in place". The problem is that
allocation process is done in two stages:
Image img;
AllocHeader( &img, .... );
/* fill other fields in the structure; imageData == NULL on return /
AllocData( &img );
/ allocate memory for image depending on the header; /
/ imageData != NULL, imageLen > 0 on return */
Unfortunately that "NULL bigarray pointer" cannot be adequately described
in caml IDL, until "unique" attribute is supported for bigarray
pointers. Even worse, if we now have NULL pointer to bigarray data passed
to caml, its runtime will silently create stat_alloc'ed 1-element array
itself. C-library will be quite surprised then ...
Hope to hear from you soon,
Dmitry
P.S.
I feel that such my messages are too much for caml-bugs :-) Maybe it's the
topic for caml mailing list? The only problem is that very few its
subscribers (if any) use camlidl ...
The text was updated successfully, but these errors were encountered:
Original bug ID: 448
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: camlidl current cvs
OS: Windows NT 4.0
The following IDL definition
typedef struct {
int imageLen;
[size_is(len),unique,bigarray] char *imageData;
} Image;
produces
type struct_1 = (char, Bigarray.int8_unsigned_elt, Bigarray.c_layout) Bigarray.Array1.t
and image = struct_1
i.e. silently ignores "unique" attribute without warning/error
message. IMHO that's not good. I'd like it to produce
type struct_1 = (char, Bigarray.int8_unsigned_elt, Bigarray.c_layout) Bigarray.Array1.t option
and someData = struct_1
as well as
typedef struct {
int imageLen;
[size_is(len),unique] char *imageData;
} Image
produces
type struct_1 = char array option
and image = struct_1
Why I need it:
There is a library that uses similar structure as an image
descriptor. "imageData" is allocated/deallocated by special library
functions, and is linked with some internal data, so "bigarray" is the only
option to access/modify it from caml "in place". The problem is that
allocation process is done in two stages:
Image img;
AllocHeader( &img, .... );
/* fill other fields in the structure; imageData == NULL on return /
AllocData( &img );
/ allocate memory for image depending on the header; /
/ imageData != NULL, imageLen > 0 on return */
Unfortunately that "NULL bigarray pointer" cannot be adequately described
in caml IDL, until "unique" attribute is supported for bigarray
pointers. Even worse, if we now have NULL pointer to bigarray data passed
to caml, its runtime will silently create stat_alloc'ed 1-element array
itself. C-library will be quite surprised then ...
Hope to hear from you soon,
Dmitry
P.S.
I feel that such my messages are too much for caml-bugs :-) Maybe it's the
topic for caml mailing list? The only problem is that very few its
subscribers (if any) use camlidl ...
The text was updated successfully, but these errors were encountered: