It was a suggested new one, and really?

/ Martin Nilsson (bygger parser

Previous text:

2003-01-04 18:00: Subject: Too many arguments

---

Never heard of it, and no.

/ Peter Bortas

Then the use of wrong_number_of_arguments-function in error.c should be reviewed. The function itself should be as well.

/ Martin Nilsson (bygger parser

Previous text:

2003-01-04 18:14: Subject: Too many arguments

---

It's an existing policy.

/ Henrik Grubbström (Lysator)

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.

1. 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

Previous text:

2003-01-04 19:31: Subject: Too many arguments

---

Which functions use that?

And what do you mean with "built in functions"?

I'm all for it, but I'm biased towards loose typing.

/ Mirar

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.

Unfortunately, it is quite common that the canonical name and the "real" name are different. I would much rather the error message said wrong number of arguments to Image.JPEG.decode than _Image_JPEG.decode (Not sure if this particular example is correct, but you get the point..)

/ Fredrik (Naranek) Hubinette (Real Build Master)

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.

1. 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

I'd like to see what variable/lookup were used in the source code to find the function (as well). That would make it even easier to debug... :)

Ie, _Image_JPEG.decode if you used _Image_JPEG.decode, Image.JPEG.decode if you used that, master()->resolve("Image")["JPEG"]->decode if you used that. :)

But I guess that's out of the question... :)

/ Mirar

Previous text:

2003-01-05 13:04: Subject: Too many arguments

---

...

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.

Unfortunately, it is quite common that the canonical name and the "real" name are different. I would much rather the error message said wrong number of arguments to Image.JPEG.decode than _Image_JPEG.decode (Not sure if this particular example is correct, but you get the point..)

/ Fredrik (Naranek) Hubinette (Real Build Master)

That's how the pike-functions work, so it would be more consistent. And you do want to have that functionality for pike functions. It is convenient to be able to write main() and not main(int x, array y, array z).

/ Martin Nilsson (bygger parser

Previous text:

2003-01-04 18:14: Subject: Too many arguments

---

Really. Explain the advantages.

/ Peter Bortas

Wrong. main() will get 3 arguments, which is more than the 0 required by its type. main() will thus have to accept more arguments than needed without throwing an error.

/ Henrik Grubbström (Lysator)

Previous text:

2003-01-04 18:24: Subject: Too many arguments

---

That is the "accept FEWER arguments without throwing an error"-policy.

/ Peter Bortas

That's a compile-time check; not a runtime check, which was what was discussed here.

/ Henrik Grubbström (Lysator)

Previous text:

2003-01-04 18:48: Subject: Too many arguments

---

Now I know we are talking past each other. A very small experiment shows that main does not accept extra args:

int main() { int done;

if(!done) { done=1; main(1,({}),({}),1,1,1,1); } }

multiarg.pike:7:Too many arguments to main. multiarg.pike:7:Expected: function( : int) multiarg.pike:7:Got : function(int(1..1), array(zero), array(zero), int(1..1), int(1..1), int(1..1), int(1..1) : void | mixed)

/ Peter Bortas

And I did mean that it should silently accept and ignore arguments outside its type declaration. E.g.

function main = sleep;

/ Martin Nilsson (bygger parser

Previous text:

2003-01-06 22:13: Subject: Too many arguments

---

It's far from obvious that "more arguments than needed" is the same thing as "more argument than required by its type", though. I interpreted the original question in the same way that ZinO seems to have done, as asking whether Pike functions should accept more arguments than the function declares a use for. That is, silently accept and ignore any arguments beyond the number of arguments that the prototype for the function requires as a maximum.

Also, isn't main() a rather poor example of a *built-in* function?

/ Leif Stensson, Lysator