right now FFIExternalEnumeration support int32 and uint32 types, but I think is not hard to create a FFIExternalLongEnumeration or whatever is need.
FFIExternalEnumeration >> initializeEnumeration, however, could be better refactored, I admit ;) > On 13 Nov 2017, at 23:41, Ben Coman <b...@openinworld.com> wrote: > > I have a C definition... > unsigned long FPDF_GetLastError(); > > whose return values are... > #define FPDF_ERR_SUCCESS 0 // No error. > #define FPDF_ERR_UNKNOWN 1 // Unknown error. > #define FPDF_ERR_FILE 2 // File not found or could not be opened. > #define FPDF_ERR_FORMAT 3 // File not in PDF format or corrupted. > #define FPDF_ERR_PASSWORD 4 // Password required or incorrect password. > #define FPDF_ERR_SECURITY 5 // Unsupported security scheme. > #define FPDF_ERR_PAGE 6 // Page not found or content error. > > I was thinking of turning those #define's into an FFIExternalEnumeration, > but I was wondering if I'll hit some undefined behaviour with the underlying > representation being a "long" rather than an "int" ? > > I do see here that C enumerations can be a range of types including "long" > * https://stackoverflow.com/questions/7093360/c-sharp-enum-of-long-values > <https://stackoverflow.com/questions/7093360/c-sharp-enum-of-long-values> > but I'm not sure how it works in the Pharo context to know what the size > underlying representation. > > cheers -ben