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

Reply via email to