638
edits
Jsctypes/api: Difference between revisions
make builtin types int and int32_t distinct on all platforms, and likewise short and int16_t etc.; also, SameType fixes
(tidying up) |
(make builtin types int and int32_t distinct on all platforms, and likewise short and int16_t etc.; also, SameType fixes) |
||
| Line 31: | Line 31: | ||
:'''<code>ctypes.size_t, ssize_t, intptr_t, uintptr_t</code>''' - Primitive types whose size depends on the platform. These types do not autoconvert to JavaScript numbers because on some platforms, there are values of these types that cannot be precisely represented as a JS number. Instead they convert to wrapper objects (on all platforms). See "64-bit integer objects" below. | :'''<code>ctypes.size_t, ssize_t, intptr_t, uintptr_t</code>''' - Primitive types whose size depends on the platform. These types do not autoconvert to JavaScript numbers because on some platforms, there are values of these types that cannot be precisely represented as a JS number. Instead they convert to wrapper objects (on all platforms). See "64-bit integer objects" below. | ||
:'''<code>ctypes.bool, short, unsigned_short, int, unsigned, unsigned_int, long, unsigned_long, float, double</code>''' - Types that behave like the corresponding C types | :'''<code>ctypes.bool, short, unsigned_short, int, unsigned, unsigned_int, long, unsigned_long, float, double</code>''' - Types that behave like the corresponding C types. As in C, <code>unsigned</code> is always an alias for <code>unsigned_int</code>. | ||
:<code>ctypes.long</code> and <code>ctypes.unsigned_long</code> autoconvert to 64-bit integer objects (on all platforms). ''(Rationale: Some platforms have 64-bit <code>long</code> and some do not.)'' The rest autoconvert to JavaScript numbers. | :<code>ctypes.long</code> and <code>ctypes.unsigned_long</code> autoconvert to 64-bit integer objects (on all platforms). ''(Rationale: Some platforms have 64-bit <code>long</code> and some do not.)'' The rest autoconvert to JavaScript numbers. | ||
| Line 432: | Line 432: | ||
* If ''t'' is a pointer type: | * If ''t'' is a pointer type: | ||
:* If ''val'' is <code>null</code>, the result is a C/C++ <code>NULL</code> pointer of type ''t''. | :* If ''val'' is <code>null</code>, the result is a C/C++ <code>NULL</code> pointer of type ''t''. | ||
:* If ''val'' is a <code>CData</code> object of array type and either ''t'' is <code>ctypes.voidptr_t</code> or | :* If ''val'' is a <code>CData</code> object of array type ''u'' and either ''t'' is <code>ctypes.voidptr_t</code> or <code>SameType(''t''.targetType, ''u''.elementType)</code>, return a pointer to the first element of the array. | ||
:* If ''t'' is <code>ctypes.voidptr_t</code> and ''val'' is a <code>CData</code> object of pointer type, return the value of the C/C++ pointer in ''val'', cast to <code>void *</code>. | :* If ''t'' is <code>ctypes.voidptr_t</code> and ''val'' is a <code>CData</code> object of pointer type, return the value of the C/C++ pointer in ''val'', cast to <code>void *</code>. | ||
:* Otherwise fail. ''(Rationale: We don't convert strings to pointers yet partly because we're lazy and partly because it would implicitly cast away const. We don't convert JavaScript arrays to pointers because this would have to allocate a C array implicitly, raising issues about who should deallocate it, and when, and how they know it's their responsibility.)'' | :* Otherwise fail. ''(Rationale: We don't convert strings to pointers yet partly because we're lazy and partly because it would implicitly cast away const. We don't convert JavaScript arrays to pointers because this would have to allocate a C array implicitly, raising issues about who should deallocate it, and when, and how they know it's their responsibility.)'' | ||
| Line 472: | Line 472: | ||
*If they are both pointer types, return <code>SameType(''t''.targetType, ''u''.targetType)</code>. | *If they are both pointer types, return <code>SameType(''t''.targetType, ''u''.targetType)</code>. | ||
*If they are both array types, return <code>SameType(''t''.elementType, ''u''.targetType) && ''t''.length === ''u''.length</code>. | *If they are both array types, return <code>SameType(''t''.elementType, ''u''.targetType) && ''t''.length === ''u''.length</code>. | ||
*If they are both | *If they are both struct types, return <code>''t'' === ''u''</code>. | ||
*Otherwise return false. | *Otherwise return false. | ||
''(<code>SameType(int, int32_t)</code> is false. Rationale: As it stands, <code>SameType</code> behaves the same on all platforms. By making types match if they are typedef'd on the current platform, we could make e.g. <code>ctypes.int.ptr</code> and <code>ctypes.int32_t.ptr</code> compatible on platforms where we just have <code>typedef int int32_t</code>. But it was unclear how much that would matter in practice, balanced against cross-platform consistency. We might reverse this decision.)'' | |||
= Examples = | = Examples = | ||