Thanks for the detailed explanation! I was wondering about those extra 
arguments and did assume something like
a coincidence/leveraging of calling conventions (and googled/brave'd "extra 
arguments c" without much luck) but good to have it confirmed.
Well now it's documented on the list at least..

-Seb

----------------------------------------------------------------------

Message: 1
Date: Mon, 18 Aug 2025 13:33:19 +0200
From: Christof Ressi <i...@christofressi.com>
Subject: [PD-dev] Re: Floats must be last in typechecked arguments to
    class_new/constructor?
To: pd-dev@lists.iem.at
Message-ID: <051b8d9c-108d-4d29-81b7-7fea53d65...@christofressi.com>
Content-Type: multipart/alternative;
    boundary="------------TWzB0i9F0EL0RjmOVvD0TIx5"

Hi Seb,

yes, that's a (little known) quirk of Pd's type-checked arguments: if 
your method signature contains a mix of float and symbols/gpointers, all 
the symbols/gpointers arguments are passed *before* all float arguments.

Take the following method, for example:

class_addmethod(foo_class, (t_method)foo_bark, gensym("bark"), A_FLOAT, 
A_SYMBOL, A_FLOAT, A_SYMBOL, 0);

The C function must then be declared like this:

void foo_bark(t_foo *x, t_symbol *arg2, t_symbol *arg4, t_floatarg arg1, 
t_floatarg arg3)
{
    // ...
}

The numbering in the arguments are supposed to show how the C function 
arguments related to the Pd method arguments.

---

Originally, this was a clever trick to avoid having a big switch 
statement in the message dispatcher. Pd only had to check the number of 
t_int arguments and then just pushed all 6 float arguments, regardless 
of the actual C function signature. This means that it would typically 
push more float arguments than the C function accepts. This happened to 
work because in all the relevant calling conventions the stack is 
cleaned up by the caller. (For example, this would have *not* worked 
with Microsoft's __stdcall.) We had to change this recently because some 
platforms, most notably WASM, are more strict about argument passing. 
Now we do have a switch statement, see mess_dispatch(), but the argument 
reordering is still useful for keeping the number of combinations down. 
If you're curious, check the implementation of pd_typedmess().

---

Personally, I tend to use A_GIMME when I have a method that mixes float 
and symbols arguments, in particular if the C function arguments would 
need to be reordered.

> I thought it had been working before but maybe I just missed it somehow..
The fun thing is that declaring the function arguments in the wrong 
order may appear to work on some platforms depending on the calling 
convention, in particular if all arguments are passed by register.
> Is this documented anywhere?
I'm not sure. Probably not :)

Christof

On 17.08.2025 18:37, Sebastian Shader via Pd-dev wrote:
> Hello list,
>      Recently I noticed one of my externals was having an error, I think it's 
>due to the typechecked argument list (when not using A_GIMME) always calling 
>methods with the floats at the end. (my external had DEFFLOAT, DEFFLOAT, 
>DEFSYMBOL).
>
>      I thought it had been working before but maybe I just missed it somehow..
>      Is this documented anywhere?
>
> Thanks,
>      -Seb
>
>      
>
>  ---
> pd-dev@lists.iem.at - the Pd developers' mailinglist
> https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/VGSB7SB26VMLC4GZ72SUFRCT5ZFKZMIU/--------------
>  next part --------------
A message part incompatible with plain text digests has been removed ...
Name: not available
Type: text/html
Size: 3695 bytes
Desc: not available

------------------------------

Subject: Digest Footer

_______________________________________________
Pd-dev mailing list -- pd-dev@lists.iem.at
To unsubscribe send an email to pd-dev-le...@lists.iem.at


------------------------------

End of Pd-dev Digest, Vol 240, Issue 11
***************************************

 ---
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/NUE2CUOUK4ZVOP5QL6JIVXLCON5A3QXY/

Reply via email to