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
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
On Fri, Feb 27, 2004 at 05:25:09PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
And even if that is added, runtime checks would frequently be necessary anyway since 0 is valid for all types (except void),
Except that there is a slight difference - function was called (intentionally) with all 0 as arguments, or bu accident (i.e. without any arguments).
There is no way (AFAIK) to check the number of arguments passed (except when explicitly specifying variable number of arguments).
Do you get a segfault in get_all_args?
Not really - somewhere outside, I guess during stack unwinding or something like this. At least, it happens while executing get_all_args(). The backtrace:
#0 0x401b276f in malloc_consolidate () from /lib/i686/libc.so.6 #1 0x401b2127 in _int_malloc () from /lib/i686/libc.so.6 #2 0x401b106c in malloc () from /lib/i686/libc.so.6 #3 0x080e4425 in debug_xalloc () #4 0x080df21d in init_mapping () #5 0x080df391 in debug_allocate_mapping () #6 0x080e278b in f_aggregate_mapping () #7 0x081896fd in file_tcgetattr () #8 0x0807712a in low_mega_apply () #9 0x08074170 in eval_instruction () #10 0x080784c8 in o_catch () #11 0x08070d45 in eval_instruction () #12 0x080783c0 in mega_apply () #13 0x080e5bf7 in call_pike_initializers () #14 0x080e5e11 in parent_clone_object () #15 0x08077538 in low_mega_apply () #16 0x080741f2 in eval_instruction () #17 0x080783c0 in mega_apply () #18 0x08079320 in apply () #19 0x080deb20 in main ()
get_all_args() was called when there were no arguments (it expected string).
The backtrace looks strange by itself...
Sure I can workaround this (don't use get_all_args() or check the number of arguments) - but anyway, there is a problem, and this function is supposed to do all this dirty job... :)
Regards, /Al
There is no way (AFAIK) to check the number of arguments passed (except when explicitly specifying variable number of arguments).
Sure there is. query_num_arg().
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-02-27 23:27: Subject: Re: Problem with function prototypes
On Fri, Feb 27, 2004 at 05:25:09PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
And even if that is added, runtime checks would frequently be necessary anyway since 0 is valid for all types (except void),
Except that there is a slight difference - function was called (intentionally) with all 0 as arguments, or bu accident (i.e. without any arguments).
There is no way (AFAIK) to check the number of arguments passed (except when explicitly specifying variable number of arguments).
Do you get a segfault in get_all_args?
Not really - somewhere outside, I guess during stack unwinding or something like this. At least, it happens while executing get_all_args(). The backtrace:
#0 0x401b276f in malloc_consolidate () from /lib/i686/libc.so.6 #1 0x401b2127 in _int_malloc () from /lib/i686/libc.so.6 #2 0x401b106c in malloc () from /lib/i686/libc.so.6 #3 0x080e4425 in debug_xalloc () #4 0x080df21d in init_mapping () #5 0x080df391 in debug_allocate_mapping () #6 0x080e278b in f_aggregate_mapping () #7 0x081896fd in file_tcgetattr () #8 0x0807712a in low_mega_apply () #9 0x08074170 in eval_instruction () #10 0x080784c8 in o_catch () #11 0x08070d45 in eval_instruction () #12 0x080783c0 in mega_apply () #13 0x080e5bf7 in call_pike_initializers () #14 0x080e5e11 in parent_clone_object () #15 0x08077538 in low_mega_apply () #16 0x080741f2 in eval_instruction () #17 0x080783c0 in mega_apply () #18 0x08079320 in apply () #19 0x080deb20 in main ()
get_all_args() was called when there were no arguments (it expected string).
The backtrace looks strange by itself...
Sure I can workaround this (don't use get_all_args() or check the number of arguments) - but anyway, there is a problem, and this function is supposed to do all this dirty job... :)
Regards, /Al
/ Brevbäraren
There is no way (AFAIK) to check the number of arguments passed (except when explicitly specifying variable number of arguments).
query_num_arg does that. You can also check if an argument has zero_type set.
Do you get a segfault in get_all_args?
Not really - somewhere outside, I guess during stack unwinding or something like this. At least, it happens while executing get_all_args(). The backtrace:
You mean, the bug happens while executing get_all_args, where the bug is that it doesn't throw a pike error, I presume. You're very welcome to whip out gdb and find out why the check for too few arguments on line 381 in src/module_support.c doesn't work.
Also, compiling pike with --with-rtldebug and without --without-cdebug (or without stripping) helps quite a lot in tracking down bugs.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-02-27 23:27: Subject: Re: Problem with function prototypes
On Fri, Feb 27, 2004 at 05:25:09PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
And even if that is added, runtime checks would frequently be necessary anyway since 0 is valid for all types (except void),
Except that there is a slight difference - function was called (intentionally) with all 0 as arguments, or bu accident (i.e. without any arguments).
There is no way (AFAIK) to check the number of arguments passed (except when explicitly specifying variable number of arguments).
Do you get a segfault in get_all_args?
Not really - somewhere outside, I guess during stack unwinding or something like this. At least, it happens while executing get_all_args(). The backtrace:
#0 0x401b276f in malloc_consolidate () from /lib/i686/libc.so.6 #1 0x401b2127 in _int_malloc () from /lib/i686/libc.so.6 #2 0x401b106c in malloc () from /lib/i686/libc.so.6 #3 0x080e4425 in debug_xalloc () #4 0x080df21d in init_mapping () #5 0x080df391 in debug_allocate_mapping () #6 0x080e278b in f_aggregate_mapping () #7 0x081896fd in file_tcgetattr () #8 0x0807712a in low_mega_apply () #9 0x08074170 in eval_instruction () #10 0x080784c8 in o_catch () #11 0x08070d45 in eval_instruction () #12 0x080783c0 in mega_apply () #13 0x080e5bf7 in call_pike_initializers () #14 0x080e5e11 in parent_clone_object () #15 0x08077538 in low_mega_apply () #16 0x080741f2 in eval_instruction () #17 0x080783c0 in mega_apply () #18 0x08079320 in apply () #19 0x080deb20 in main ()
get_all_args() was called when there were no arguments (it expected string).
The backtrace looks strange by itself...
Sure I can workaround this (don't use get_all_args() or check the number of arguments) - but anyway, there is a problem, and this function is supposed to do all this dirty job... :)
Regards, /Al
/ Brevbäraren
On Fri, Feb 27, 2004 at 11:45:03PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
to whip out gdb and find out why the check for too few arguments on line 381 in src/module_support.c doesn't work.
This is quite easy, why it doesn't - since before this check there is another (line 373):
if (ret <= args) and, of course, value of "ret" is 0, value of "args" is 0 too, so... :)
I guess, the number of arguments must be checked first... But I wonder why this bug doesn't happen in 7.4 (same check order)...
Also, compiling pike with --with-rtldebug and without --without-cdebug (or without stripping) helps quite a lot in tracking down bugs.
Perhaps, you mean --with-cdebug? I did so, but without RTL debug code. No idea why gdb shows no args in backtrace... Anyway, the backtrace is strange (perhaps because of longjmp() - there is no trace of get_all_args()).
Regards, /Al
How does your calling code to get_all_args look like?
I can't repeat the bug.
/ Mirar
Previous text:
2004-02-28 04:30: Subject: Re: Problem with function prototypes
On Fri, Feb 27, 2004 at 11:45:03PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
to whip out gdb and find out why the check for too few arguments on line 381 in src/module_support.c doesn't work.
This is quite easy, why it doesn't - since before this check there is another (line 373):
if (ret <= args)
and, of course, value of "ret" is 0, value of "args" is 0 too, so... :)
I guess, the number of arguments must be checked first... But I wonder why this bug doesn't happen in 7.4 (same check order)...
Also, compiling pike with --with-rtldebug and without --without-cdebug (or without stripping) helps quite a lot in tracking down bugs.
Perhaps, you mean --with-cdebug? I did so, but without RTL debug code. No idea why gdb shows no args in backtrace... Anyway, the backtrace is strange (perhaps because of longjmp() - there is no trace of get_all_args()).
Regards, /Al
/ Brevbäraren
On Sat, Feb 28, 2004 at 08:10:05AM +0100, Mirar @ Pike developers forum wrote:
How does your calling code to get_all_args look like?
Like this:
static void object_tokenize(INT32 args) { struct pike_string *s = 0; int n = 0;
if (!THIS->re) Pike_error("No RE compiled to tokenize by!\n");
fprintf(stderr, "getting args\n"); get_all_args("PCRE()->tokenize", args, "%S", &s); fprintf(stderr, "got args: %p\n", s); /// ... more stuff }
It fails after printing "getting args", somewhere deep inside the interpreter.
I changed checking order in get_all_args(), so test for correct number of arguments will be done first, now everything is OK.
What is strange - I can't reproduce this bug in isolated function (i.e. outside object)... But valgrind shows no problems...
It was working without any problems in 7.4, and when I tried to "port" it to 7.5, this problem arised...
Regards, /Al
This is quite easy, why it doesn't - since before this check there is another (line 373):
if (ret <= args)
and, of course, value of "ret" is 0, value of "args" is 0 too, so... :)
Yes, that looks bogus. It should be < there.
But I wonder why this bug doesn't happen in 7.4 (same check order)...
The bug was that a freed svalue on the stack was copied into the exception struct if the function was called with no arguments. That only led to a failure if the stack svalue pointed to a refcounted value of some sort. So whether or not you get the bug depended on the code further up. It took me a while to figure out a test that consistently trigs it:
void trig_bug() { lambda (mixed a, mixed b, mixed c) {} (({time()}), ({time()}), ({time()})); // set_weak_flag uses get_all_args and requires two arguments. ([function] set_weak_flag)(); }
I guess there's some kind of subtle difference in the stack handling between 7.4 and 7.5 that caused it to happen only in 7.5 in your case.
Also, compiling pike with --with-rtldebug and without --without-cdebug (or without stripping) helps quite a lot in tracking down bugs.
Perhaps, you mean --with-cdebug?
That should work too, but since it's the default I did actually mean without --without-cdebug.
No idea why gdb shows no args in backtrace...
The binary doesn't get stripped somewhere? When I hack Pike on the C level, I usually compile it with a plain "make" and run it directly in the build tree through the bin/pike script. It's not stripped then, at least.
Anyway, the backtrace is strange (perhaps because of longjmp() - there is no trace of get_all_args()).
That was because the use of the bogus svalue caused an error first when the exception is handled.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-02-28 04:30: Subject: Re: Problem with function prototypes
On Fri, Feb 27, 2004 at 11:45:03PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
to whip out gdb and find out why the check for too few arguments on line 381 in src/module_support.c doesn't work.
This is quite easy, why it doesn't - since before this check there is another (line 373):
if (ret <= args)
and, of course, value of "ret" is 0, value of "args" is 0 too, so... :)
I guess, the number of arguments must be checked first... But I wonder why this bug doesn't happen in 7.4 (same check order)...
Also, compiling pike with --with-rtldebug and without --without-cdebug (or without stripping) helps quite a lot in tracking down bugs.
Perhaps, you mean --with-cdebug? I did so, but without RTL debug code. No idea why gdb shows no args in backtrace... Anyway, the backtrace is strange (perhaps because of longjmp() - there is no trace of get_all_args()).
Regards, /Al
/ Brevbäraren
While looking at get_all_args, I noted that it doesn't check for too many arguments. In a few cases, like mktime, that's exploited to take care of some optional arguments afterwards. In the majority of cases however it just makes the functions too forgiving for argument errors (c.f. code generated from cmods that normally doesn't allow too many arguments).
I'm thinking of adding support for optional arguments to get_all_args and to let it check for too many arguments. That means that it would complain by default, which is incompatible (notwithstanding a provision for 7.4 compat mode, which of course should be added). Opinions?
/ Martin Stjernholm, Roxen IS
Previous text:
2004-02-28 21:18: Subject: Re: Problem with function prototypes
This is quite easy, why it doesn't - since before this check there is another (line 373):
if (ret <= args)
and, of course, value of "ret" is 0, value of "args" is 0 too, so... :)
Yes, that looks bogus. It should be < there.
But I wonder why this bug doesn't happen in 7.4 (same check order)...
The bug was that a freed svalue on the stack was copied into the exception struct if the function was called with no arguments. That only led to a failure if the stack svalue pointed to a refcounted value of some sort. So whether or not you get the bug depended on the code further up. It took me a while to figure out a test that consistently trigs it:
void trig_bug() { lambda (mixed a, mixed b, mixed c) {} (({time()}), ({time()}), ({time()})); // set_weak_flag uses get_all_args and requires two arguments. ([function] set_weak_flag)(); }
I guess there's some kind of subtle difference in the stack handling between 7.4 and 7.5 that caused it to happen only in 7.5 in your case.
Also, compiling pike with --with-rtldebug and without --without-cdebug (or without stripping) helps quite a lot in tracking down bugs.
Perhaps, you mean --with-cdebug?
That should work too, but since it's the default I did actually mean without --without-cdebug.
No idea why gdb shows no args in backtrace...
The binary doesn't get stripped somewhere? When I hack Pike on the C level, I usually compile it with a plain "make" and run it directly in the build tree through the bin/pike script. It's not stripped then, at least.
Anyway, the backtrace is strange (perhaps because of longjmp() - there is no trace of get_all_args()).
That was because the use of the bogus svalue caused an error first when the exception is handled.
/ Martin Stjernholm, Roxen IS
Add semantics to check for too many options, instead?
Maybe a "%$" or something?
(I never realised why too many options is a bad thing. But then again, I don't use strong typing either...)
/ Mirar
Previous text:
2004-02-28 21:51: Subject: Re: Problem with function prototypes
While looking at get_all_args, I noted that it doesn't check for too many arguments. In a few cases, like mktime, that's exploited to take care of some optional arguments afterwards. In the majority of cases however it just makes the functions too forgiving for argument errors (c.f. code generated from cmods that normally doesn't allow too many arguments).
I'm thinking of adding support for optional arguments to get_all_args and to let it check for too many arguments. That means that it would complain by default, which is incompatible (notwithstanding a provision for 7.4 compat mode, which of course should be added). Opinions?
/ Martin Stjernholm, Roxen IS
Well, the point would be to improve the error checking in the vast majority of cases where the check for too many arguments is neglected.
(I never realised why too many options is a bad thing. /.../
It's bad because it can mask programming mistakes. In that case, the question rather becomes: What good is it? I can only think of cases with some sort of generalized function call dispatch, but that gets very contrived.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-02-28 21:56: Subject: Re: Problem with function prototypes
Add semantics to check for too many options, instead?
Maybe a "%$" or something?
(I never realised why too many options is a bad thing. But then again, I don't use strong typing either...)
/ Mirar
Another reason it's bad is that if too many arguments are "officially" accepted, functions can not be extended to take more arguments without compatibility considerations.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-02-28 22:08: Subject: Re: Problem with function prototypes
Well, the point would be to improve the error checking in the vast majority of cases where the check for too many arguments is neglected.
(I never realised why too many options is a bad thing. /.../
It's bad because it can mask programming mistakes. In that case, the question rather becomes: What good is it? I can only think of cases with some sort of generalized function call dispatch, but that gets very contrived.
/ Martin Stjernholm, Roxen IS
Not really related, but with plugin-like functions (in Pike code) it is very convenient to not have to take care of all arguments the framework calls the function with. And you can extend the framework to give more arguments without too great compatibility concerns.
/ Martin Nilsson (saturator)
Previous text:
2004-02-28 22:08: Subject: Re: Problem with function prototypes
Well, the point would be to improve the error checking in the vast majority of cases where the check for too many arguments is neglected.
(I never realised why too many options is a bad thing. /.../
It's bad because it can mask programming mistakes. In that case, the question rather becomes: What good is it? I can only think of cases with some sort of generalized function call dispatch, but that gets very contrived.
/ Martin Stjernholm, Roxen IS
Good point. It's very klunky to have to end them with ", mixed... dummy" in that case.
Still, I think those cases also are only a fairly few exceptions when it comes to C level functions.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-02-28 23:07: Subject: Re: Problem with function prototypes
Not really related, but with plugin-like functions (in Pike code) it is very convenient to not have to take care of all arguments the framework calls the function with. And you can extend the framework to give more arguments without too great compatibility concerns.
/ Martin Nilsson (saturator)
I'm using that feature heavilty in the Subversion module, and I would get at least a little bit pissed if you broke it.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-02-28 21:51: Subject: Re: Problem with function prototypes
While looking at get_all_args, I noted that it doesn't check for too many arguments. In a few cases, like mktime, that's exploited to take care of some optional arguments afterwards. In the majority of cases however it just makes the functions too forgiving for argument errors (c.f. code generated from cmods that normally doesn't allow too many arguments).
I'm thinking of adding support for optional arguments to get_all_args and to let it check for too many arguments. That means that it would complain by default, which is incompatible (notwithstanding a provision for 7.4 compat mode, which of course should be added). Opinions?
/ Martin Stjernholm, Roxen IS
It would be considerable work to adapt the code, then? How many functions is it?
/ Martin Stjernholm, Roxen IS
Previous text:
2004-02-29 01:15: Subject: Re: Problem with function prototypes
I'm using that feature heavilty in the Subversion module, and I would get at least a little bit pissed if you broke it.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Still less than those that have missing checks, I believe. Why would a max argument check get in the way? Do you implement optional arguments like f_mktime or is it a plugin style interface as Nilsson mentioned?
/ Martin Stjernholm, Roxen IS
Previous text:
2004-02-29 02:21: Subject: Re: Problem with function prototypes
Around 50.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
It's optional arguments.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-02-29 02:54: Subject: Re: Problem with function prototypes
Still less than those that have missing checks, I believe. Why would a max argument check get in the way? Do you implement optional arguments like f_mktime or is it a plugin style interface as Nilsson mentioned?
/ Martin Stjernholm, Roxen IS
I've added a feature to get_all_args so that optional arguments can be defined - put a period before the first one. It can simplify the code a bit.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-02-29 13:02: Subject: Re: Problem with function prototypes
It's optional arguments.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Not really. Having to add #ifdef:s to check whether this feature is available to each function would make things more complex, not simpler.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-02-29 17:03: Subject: Re: Problem with function prototypes
I've added a feature to get_all_args so that optional arguments can be defined - put a period before the first one. It can simplify the code a bit.
/ Martin Stjernholm, Roxen IS
Besides, several of the optional parameters can't be parsed properly with the conversion operators provided by get_all_args. I need to use my own custom argument checking functions for them.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-02-29 17:10: Subject: Re: Problem with function prototypes
Not really. Having to add #ifdef:s to check whether this feature is available to each function would make things more complex, not simpler.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
%* can be useful if there are only a few such arguments among easily parsed ones.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-02-29 17:12: Subject: Re: Problem with function prototypes
Besides, several of the optional parameters can't be parsed properly with the conversion operators provided by get_all_args. I need to use my own custom argument checking functions for them.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Yes, but there aren't. The optional arguments are almost exclusively of two kinds which need special handling.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-02-29 17:15: Subject: Re: Problem with function prototypes
%* can be useful if there are only a few such arguments among easily parsed ones.
/ Martin Stjernholm, Roxen IS
It can still make things simpler, but apparently not in your case.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-02-29 17:10: Subject: Re: Problem with function prototypes
Not really. Having to add #ifdef:s to check whether this feature is available to each function would make things more complex, not simpler.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Giving too many arguments to a pike function is not an error at runtime.
/ Henrik Grubbström (Lysator)
Previous text:
2004-02-29 02:54: Subject: Re: Problem with function prototypes
Still less than those that have missing checks, I believe. Why would a max argument check get in the way? Do you implement optional arguments like f_mktime or is it a plugin style interface as Nilsson mentioned?
/ Martin Stjernholm, Roxen IS
It is for normal cmod generated functions, and a bunch of other ones. Whether it should be or not is what's being discussed here. I think it should be allowed only in special cases.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-02-29 13:35: Subject: Re: Problem with function prototypes
Giving too many arguments to a pike function is not an error at runtime.
/ Henrik Grubbström (Lysator)
There is no way (AFAIK) to check the number of arguments passed (except when explicitly specifying variable number of arguments).
Three ways,
1) query_num_arg()
2) using a function type that gives you the arguments as an array, for instance:
void my_func(int|string ... args)
3) testing the arguments with zero_type
/ Mirar
Previous text:
2004-02-27 23:27: Subject: Re: Problem with function prototypes
On Fri, Feb 27, 2004 at 05:25:09PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
And even if that is added, runtime checks would frequently be necessary anyway since 0 is valid for all types (except void),
Except that there is a slight difference - function was called (intentionally) with all 0 as arguments, or bu accident (i.e. without any arguments).
There is no way (AFAIK) to check the number of arguments passed (except when explicitly specifying variable number of arguments).
Do you get a segfault in get_all_args?
Not really - somewhere outside, I guess during stack unwinding or something like this. At least, it happens while executing get_all_args(). The backtrace:
#0 0x401b276f in malloc_consolidate () from /lib/i686/libc.so.6 #1 0x401b2127 in _int_malloc () from /lib/i686/libc.so.6 #2 0x401b106c in malloc () from /lib/i686/libc.so.6 #3 0x080e4425 in debug_xalloc () #4 0x080df21d in init_mapping () #5 0x080df391 in debug_allocate_mapping () #6 0x080e278b in f_aggregate_mapping () #7 0x081896fd in file_tcgetattr () #8 0x0807712a in low_mega_apply () #9 0x08074170 in eval_instruction () #10 0x080784c8 in o_catch () #11 0x08070d45 in eval_instruction () #12 0x080783c0 in mega_apply () #13 0x080e5bf7 in call_pike_initializers () #14 0x080e5e11 in parent_clone_object () #15 0x08077538 in low_mega_apply () #16 0x080741f2 in eval_instruction () #17 0x080783c0 in mega_apply () #18 0x08079320 in apply () #19 0x080deb20 in main ()
get_all_args() was called when there were no arguments (it expected string).
The backtrace looks strange by itself...
Sure I can workaround this (don't use get_all_args() or check the number of arguments) - but anyway, there is a problem, and this function is supposed to do all this dirty job... :)
Regards, /Al
/ Brevbäraren
pike-devel@lists.lysator.liu.se
-
Alexander Demenshin -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Nilsson (saturator) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum