Jsctypes/api: Difference between revisions

# '''Lifetimes.''' This problem arises when autoconverting from JS to C/C++ only.

:When passing a string to a foreign function, like <code>foo(s)</code>, what is the lifetime of the autoconverted pointer? We're comfortable with guaranteeing <code>s</code> for the duration of the call. But then there are situations like

:The more implicit conversion we allow, the greater a problem this is; it's a tough trade-off.

# '''Non-null-terminated strings.''' This problem arises when autoconverting from C/C++ to JS only. It applies to C/C++ character arrays as well as pointers (but it's worse when dealing with pointers).

:In C/C++, the type <code>char *</code> effectively promises nothing about the pointed-to data. Autoconverting would make it hard to use APIs that return non-null-terminated strings (or structs containing <code>char *</code> pointers that aren't logically strings). The workaround would be to declare them as a different type.

# '''Unicode.''' This problem does not apply to conversions between JS strings and <code>jschar</code> arrays or pointers; only <code>char</code> arrays or pointers.

:Converting both ways raises issues about what encoding should be assumed. We assume JS strings are UTF-16 and <code>char</code> strings are UTF-8, which is not the right thing on Windows. However Windows offers a lot of APIs that accept 16-bit strings, and for those <code>jschar</code> is the right thing.

# '''Casting away const.''' This problem arises only when converting from a JS string to a C/C++ pointer type.  The string data must not be modified, but the C/C++ types <code>char *</code> and <code>jschar *</code> suggest that the referent might be modified.