Smalltalk › Pharo › Pharo Smalltalk Users

FFIExternalEnumeration int versus long

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Ben Coman

FFIExternalEnumeration int versus long

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

EstebanLM

Re: FFIExternalEnumeration int versus long

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 <[hidden email]> 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

tblanchard

Re: FFIExternalEnumeration int versus long

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.

On Nov 14, 2017, at 2:44 AM, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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

Ben Coman

Re: FFIExternalEnumeration int versus long

On 15 November 2017 at 00:17, Todd Blanchard <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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