I see. The error string is preferably generated runtime... Also, depending on how much effort one wants to put into it, many functions could probably be changed to use get_all_args et al.
I think that no function should throw an error if it's given too many arguments run-time. That behaviour is also common for C. I don't know if it's a standard.
But I wouldn't want oversimplification. Verbose error messages is useful, it helps the process of mending your program.
Errors like "Too few arguments" without mention how many arguments it want, "Bad arguments" without mentioning what type of arguments it expected, and not mentioning the function that has the issue is worthless. A core is easier to debug... :)
/ Mirar
Previous text:
2003-01-04 21:20: Subject: Too many arguments
Just grep for wrong_number_of_args and you'll get 334 matches, so I'll guess there's around 332 functions that throws when you give them more arguments than they need. With built in I really meant C functions.
I can give a little background to this exploration as well. I looked at the strings in the Pike binary and found that there was a great number of similar looking error messages ("Bad argument 2 to exece()", "Bad argument 1 to exece()", "Bad argument 1 to mv()" etc). Rewriting into using SIMPLE_TOO_FEW_ARGS_ERROR and SIMPLE_BAD_ARG_ERROR helps a lot, but it should be possible to do a lot better.
- These are macros that expands to verbose function call. A special
function for this very common task might be good. 2. One should not need to state the function name in every error call. It must be available somewhere for the error handling to read straight out. Not only would this save memory, it would also save us from having alarm() say "Too few arguments to signame()". Having the error handling take care of this also ensures that the name of the failing function is printed out at all. 3. One should not need to state the correct type for an argument in a string. All the correct types should already be known and be available for the error handling to read and use.
I know too little about Pike internals and C to solve these (at least 2 and 3) though.
/ Martin Nilsson (bygger parser