[Pharo-project] [NativeBoost] Generic failure errors when using nil for void* and char* arguments
Hello, I use NativeBoost to call some icu4c functions. This works fine most of the time. But now I run into the problem that when I pass nil as the argument value for one or more void* / char* parameters I get an error. When I pass a value or an empty ByteArray than it works. According to the icu4c documentation I should be able to pass NULL as an argument value. What am I missing? Jan.
On 20 April 2012 15:59, Jan van de Sandt <jvdsandt@gmail.com> wrote:
Hello,
I use NativeBoost to call some icu4c functions. This works fine most of the time. But now I run into the problem that when I pass nil as the argument value for one or more void* / char* parameters I get an error. When I pass a value or an empty ByteArray than it works.
According to the icu4c documentation I should be able to pass NULL as an argument value.
What am I missing?
For pointers, there is an options in callouts, #optCoerceNilToNull which should be set, then you can invoke the call with nil as argument, which will convert it to C NULL. By default this option is OFF, because extra check means extra cycles. You can control a callout options by either per function call (see NBBasicExamples>>readDoubleFrom:) or for all methods of your class as a whole, like: MyClass class>>ffiCalloutOptions "by default, return all pointers as an instance of external address " ^ #( + optReturnPtrAsExternalAddress + optCoerceNilToNull "passing nil as pointer, will convert it to null(0) " )
Jan.
-- Best regards, Igor Stasenko.
Yes, now it works! Thanks Igor. On Fri, Apr 20, 2012 at 4:46 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 20 April 2012 15:59, Jan van de Sandt <jvdsandt@gmail.com> wrote:
Hello,
I use NativeBoost to call some icu4c functions. This works fine most of the time. But now I run into the problem that when I pass nil as the argument value for one or more void* / char* parameters I get an error. When I pass a value or an empty ByteArray than it works.
According to the icu4c documentation I should be able to pass NULL as an argument value.
What am I missing?
For pointers, there is an options in callouts, #optCoerceNilToNull which should be set, then you can invoke the call with nil as argument, which will convert it to C NULL.
By default this option is OFF, because extra check means extra cycles.
You can control a callout options by either per function call (see NBBasicExamples>>readDoubleFrom:) or for all methods of your class as a whole, like:
MyClass class>>ffiCalloutOptions "by default, return all pointers as an instance of external address " ^ #( + optReturnPtrAsExternalAddress + optCoerceNilToNull "passing nil as pointer, will convert it to null(0) " )
Jan.
-- Best regards, Igor Stasenko.
Sig, I wonder whether that should be on by default. I have had some real frustrations with FFI of late, and something like this might have avoided the problem. Unless it is easily discoverable, off is almost the same as non-existent. Any rumblings on Spock? It would be nice to have even a facade that unifies the FFI/NB/Alien on all platforms. It would indelicate to mention that this was supposed to happen in January<g>. I never really expected to see it that soon, given the problems I had going from 1.1.1 to 1.3 with FFI, and my rotating errors with Alien callbacks. I changed a bunch of FFI calls (in ways that I genuinely think should not have been necessary) and retreated to C functions for GSL callbacks. The latter is frustrating, BAD for my eventually being able to release a GSL binding (make that REALLY BAD), but not all bad because C++ is a better formula translator that Smalltalk, and the number crunching runs at native speeds. I think these things *can* work - they just don't at present, and the FFI/NB/Alien split makes it hard to know what to try. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua@gmail.com] Sent: Friday, April 20, 2012 10:46 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [NativeBoost] Generic failure errors when using nil for void* and char* arguments On 20 April 2012 15:59, Jan van de Sandt <jvdsandt@gmail.com> wrote:
Hello,
I use NativeBoost to call some icu4c functions. This works fine most of the time. But now I run into the problem that when I pass nil as the argument value for one or more void* / char* parameters I get an error. When I pass a value or an empty ByteArray than it works.
According to the icu4c documentation I should be able to pass NULL as an argument value.
What am I missing?
For pointers, there is an options in callouts, #optCoerceNilToNull which should be set, then you can invoke the call with nil as argument, which will convert it to C NULL. By default this option is OFF, because extra check means extra cycles. You can control a callout options by either per function call (see NBBasicExamples>>readDoubleFrom:) or for all methods of your class as a whole, like: MyClass class>>ffiCalloutOptions "by default, return all pointers as an instance of external address " ^ #( + optReturnPtrAsExternalAddress + optCoerceNilToNull "passing nil as pointer, will convert it to null(0) " )
Jan.
-- Best regards, Igor Stasenko.
On 20 April 2012 17:45, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Sig,
I wonder whether that should be on by default. Â I have had some real frustrations with FFI of late, and something like this might have avoided the problem. Â Unless it is easily discoverable, off is almost the same as non-existent.
Well, it depends on POV. For the strictness of usage, i thought it is better to pass explicitly (NBExternalAddress value: 0) than nil, so that your code passing correct value types to function(s). Automatic coercion and weak typing is something which i hate in C, and try to avoid (smalltalk is strong typed language) i.e. unsigned long a = 10000000; char x = a; producing only a compiler warning. and if you put: char x = (char) a; you can suppress it. But this is like placing a time bomb into your code, which you never know when it will explode. Weak typing is common source of many errors and bugs which is hard to find. This is one of the reasons, why i don't want nil to be a valid argument for functions expecting pointer(s) by default. Because while some library functions say that NULL is valid argument, on opposite side, there another functions which expecting a valid pointer value, and if you pass nil (as a result of not fully initialized object), you will crash the application.
Any rumblings on Spock? Â It would be nice to have even a facade that unifies the FFI/NB/Alien on all platforms. Â It would indelicate to mention that this was supposed to happen in January<g>.
Yes, i am lazy guy, who cannot do much. Sorry :) The plans are still there: add callbacks support, add threading, unify Alien and NB.
I never really expected to see it that soon, given the problems I had going from 1.1.1 to 1.3 with FFI, and my rotating errors with Alien callbacks. Â I changed a bunch of FFI calls (in ways that I genuinely think should not have been necessary) and retreated to C functions for GSL callbacks. Â The latter is frustrating, BAD for my eventually being able to release a GSL binding (make that REALLY BAD), but not all bad because C++ is a better formula translator that Smalltalk, and the number crunching runs at native speeds.
I think these things *can* work - they just don't at present, and the FFI/NB/Alien split makes it hard to know what to try.
i want that everything start working too.. so i can move on oh higher levels, since NativeBoost is infrastructural kind of project.
Bill
-- Best regards, Igor Stasenko.
oh, and as meta-comment, i should add a more comprehensible error message, like 'FFI Callout failed, when trying to coerce arguments' or something like that, instead of 'Generic failure' which is just a sign that primitive failed and no call were performed. But right now, just keep that in mind: every time you got a generic error in FFI callout, first thing you should look at is what are you passing as arguments, and what is C function expects. -- Best regards, Igor Stasenko.
Sig, For the record, you are not lazy. We'll start to live long and prosper when you get to it. Thanks! Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua@gmail.com] Sent: Friday, April 20, 2012 12:08 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [NativeBoost] Generic failure errors when using nil for void* and char* arguments On 20 April 2012 17:45, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Sig,
I wonder whether that should be on by default. I have had some real frustrations with FFI of late, and something like this might have avoided the problem. Unless it is easily discoverable, off is almost the same as non-existent.
Well, it depends on POV. For the strictness of usage, i thought it is better to pass explicitly (NBExternalAddress value: 0) than nil, so that your code passing correct value types to function(s). Automatic coercion and weak typing is something which i hate in C, and try to avoid (smalltalk is strong typed language) i.e. unsigned long a = 10000000; char x = a; producing only a compiler warning. and if you put: char x = (char) a; you can suppress it. But this is like placing a time bomb into your code, which you never know when it will explode. Weak typing is common source of many errors and bugs which is hard to find. This is one of the reasons, why i don't want nil to be a valid argument for functions expecting pointer(s) by default. Because while some library functions say that NULL is valid argument, on opposite side, there another functions which expecting a valid pointer value, and if you pass nil (as a result of not fully initialized object), you will crash the application.
Any rumblings on Spock? It would be nice to have even a facade that unifies the FFI/NB/Alien on all platforms. It would indelicate to mention that this was supposed to happen in January<g>.
Yes, i am lazy guy, who cannot do much. Sorry :) The plans are still there: add callbacks support, add threading, unify Alien and NB.
I never really expected to see it that soon, given the problems I had going from 1.1.1 to 1.3 with FFI, and my rotating errors with Alien callbacks. I changed a bunch of FFI calls (in ways that I genuinely think should not have been necessary) and retreated to C functions for GSL callbacks. The latter is frustrating, BAD for my eventually being able to release a GSL binding (make that REALLY BAD), but not all bad because C++ is a better formula translator that Smalltalk, and the number crunching runs at native speeds.
I think these things *can* work - they just don't at present, and the FFI/NB/Alien split makes it hard to know what to try.
i want that everything start working too.. so i can move on oh higher levels, since NativeBoost is infrastructural kind of project.
Bill
-- Best regards, Igor Stasenko.
participants (3)
-
Igor Stasenko -
Jan van de Sandt -
Schwab,Wilhelm K