On 15 November 2017 at 00:17, Todd Blanchard <tblanch...@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 <esteba...@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 <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
> 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