On 15 November 2017 at 00:17, Todd Blanchard <tblanchard@mac.com> wrote:
Yeah, I don't know if that is necessarily worth doing TBH.
Generally enumerations are going to be default int size unless you have values that are out of range.
In this case you have a function that returns a long. In a strictly typed language you would be required to do a type cast anyhow.
If this were done in Swift, you'd have to do something heinous like
FPDF_ERR.fromRaw(FPDF_GetLastError()) // older Swift FPDF_ERR(rawValue: FPDF_GetLastError())
even C++ would require you cast from unsigned long to the enum type.
So, to me, it makes sense with this kind of api that you'd have to explicitly convert in the method that does the ffiCall:, get the result, then look up the proper enum.
To clarify, in this case its not a technical enumeration in the C header to be passed around the library, just a bunch of 10 defines for error return values. Initially I was thinking of doing it in Pharo as an enumeration just because they are numbers, but the GetLastError() function return type was 'long' so it made me curious. Now I've reevaluated I think it will work better to create a Error class to raise for each return value. Thanks for your thoughts. cheers -ben
On Nov 14, 2017, at 2:44 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
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 <btc@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 but I'm not sure how it works in the Pharo context to know what the size underlying representation.
cheers -ben