Right now we have VOID, explicitly sized integers (INT32 etc), FLOAT, DOUBLE, BOOL, STRING (char*), and USTRING (PRUnichar*). We should add: * char, signed char, unsigned char, short, unsigned short, ..., long long, unsigned long long * long double * wchar_t, wchar_t* (2 or 4 byte strings, depending on plat) * size_t, ssize_t, ptrdiff_t, intptr_t, uintptr_t * void* (voidptr_t?) ... and rename existing types to fit in with our proposed API. This ties in with bug 513788 but can be done separately, depending on how long that work takes.
python prior art has c_char c_wchar c_byte c_ubyte c_short c_ushort c_int c_uint c_long c_ulong c_longlong c_ulonglong c_float c_double c_longdouble c_char_p c_wchar_p c_void_p I agree we want size_t, ssize_t, ptrdiff_t, intpt_t, uintptr_t What's this about renaming the existing types? What's wrong with them?
(In reply to comment #1) > What's this about renaming the existing types? What's wrong with them? We should do s/INT32/int32_t/ if we're going to be consistent. (We can do that now if we're settled on the latter!)
We should also move the current types from ctypes.types.x to ctypes.x if that's the way we're going. I propose we wait a bit 'til we're settled on the API and then do all this before the final 1.9.2 beta.
Oh, I for some reason thought that one of the original patch revisions had renamed INT32->int32_t. We should do that ASAP. And sure, we can hang the types off of ctypes directly. For now even we could just do int32_t = nsIForeignLibrary.INT32;
Component: js-ctypes → js-ctypes
Product: Other Applications → Core
Version: Trunk → unspecified
Existing types renamed and moved per bug 518721.
Fixed per bug 513788.
Assignee: nobody → dwitte
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.