Feature #22066
open
MemoryView feedbacks: error reporting and lack of formats
Description
Hello.
I have been doing small-scale development involving MemoryView for the past two or three years, and I would like to report two use cases I encountered.
No way to communicate the reason for failure¶
rb_memory_view_get_func_t returns false when there is a problem, but it would be helpful if the type of problem could also be communicated to the caller - for example, whether the requested flags are not supported, or whether there is an issue with the object's state. In Ruby, exceptions are normally used for this purpose. However, as far as I understand, rb_memory_view_get_func_t is currently designed as a boolean-returning function, and there is no documented way to return a structured failure reason while still returning false.
Currently I output the problem with rb_warn before returning false. Would it be possible to add an output parameter for an exception, for example:
typedef bool (* rb_memory_view_get_func_t)(VALUE obj, rb_memory_view_t *view, int flags);
|
v
typedef bool (* rb_memory_view_get_func_t)(VALUE obj, rb_memory_view_t *view, int flags, VALUE *error);
or, add a member function to retrieve the error?
Insufficient format support¶
When I tried to export GStreamer gem data as a MemoryView, I found that some formats were missing. GStreamer supports formats such as 24-bit little-endian integers (S24LE), but these could not be expressed using MemoryView's format strings. The size alone can be represented by combining existing format characters like ccc, but the semantics are different.
Furthermore, there are formats such as S24_32LE, where the storage width is 32 bits but the valid bit depth is 24 bits. This also cannot be expressed in the current MemoryView specification.
I don't use these formats myself, and since GStreamer appears to be defined quite broadly, I suspect others don't use them much either - but I'm reporting the limitation as a fact. Would it be feasible to either add new format strings, or to express item characteristics using a combination of sign, type, size, and endianness (such as S24LE)?
As I have only been working in this area in a limited and intermittent way, these proposals may be narrow in perspective, but I hope they can be of some reference for future development. Please feel free to ask if anything needs more detail.
Updated by