As I understand, this is exactly because of absense of type declaration in latter case, but... Is it intended to behave like this?
Yes. You can enable warnings for it with the strict_types pragma. The compiler will then warn about calling a mixed value since untyped->method hasn't got a type and is therefore assumed to be mixed.
Sure, run-time prototype checking is expensive, but... It's absense may lead to some strange application behavior, especially in C module (do I've to call pop_n_elems(args) regardless of function prototype?). After all, it places responsibility to check all arguments to the developer, explicitly (so it has to be done anyway).
Indeed, and the type checks in the compiler is (currently) no substitute for that since there's no runtime API where strong typing can be assumed. In cases where the compiler can guarantee that all arguments have the correct types, we could introduce an alternate API for both Pike and C functions that bypass the runtime argument checks, but there's no such thing today.
And even if that is added, runtime checks would frequently be necessary anyway since 0 is valid for all types (except void), and an integer can always be a bignum object. So I don't think there'd be any significant gain. In practice only the checks of the number of arguments would be avoided.
So, when this method is accessed through generic typed variable (object re) without arguments, I get segfault in 7.5, while in 7.4 everything is OK (error is thrown with no [visible] side effects).
Do you get a segfault in get_all_args?
I wonder what will happen if function will be called with arguments while it accepts none (and there is no pop_n_elems(args) call)...
You will get an inconsistent stack. You have to handle any number of arguments to your functions.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-02-27 12:49: Subject: Problem with function prototypes
Hi,
Doing some tests, I discovered interesting behavior... Say, we have the following:
class Test { string method(int n, string s) { // ...blabla } }
And some declarations:
Test typed = Test(); object untyped = Test();
So now, when I try to call typed->method(), the prototype will be checked, but when I call untyped->method(), it won't (and all arguments will be 0).
As I understand, this is exactly because of absense of type declaration in latter case, but... Is it intended to behave like this?
Sure, run-time prototype checking is expensive, but... It's absense may lead to some strange application behavior, especially in C module (do I've to call pop_n_elems(args) regardless of function prototype?). After all, it places responsibility to check all arguments to the developer, explicitly (so it has to be done anyway).
Concerning C modules... I have something like this:
void object_match(INT32 args) { struct pike_string *s; // ... get_all_args("match", args, "%S", &s); // ... }
And prototype defintion like this (in pike_module_init()):
add_function("match", object_match, "function(string:int)", 0);So, when this method is accessed through generic typed variable (object re) without arguments, I get segfault in 7.5, while in 7.4 everything is OK (error is thrown with no [visible] side effects).
I wonder what will happen if function will be called with arguments while it accepts none (and there is no pop_n_elems(args) call)...
Do I do something wrong? Or this is a bug somewhere?
Regards, /Al
/ Brevbäraren