[PD] arguments not passed to an external
martin.peach at sympatico.ca
Tue May 27 05:22:09 CEST 2014
On 2014-05-26 20:30, Jonathan Wilkes wrote:
> On 05/26/2014 07:50 PM, Martin Peach wrote:
>> On 2014-05-26 19:03, Jonathan Wilkes wrote:
>>> On 05/26/2014 04:28 AM, IOhannes m zmoelnig wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA256
>>>> On 2014-05-26 09:35, Alexandros Drymonitis wrote:
>>>>>> void *tabPowSine_new(t_symbol *s, short argc, t_atom *argv)
>>>> short argc? why short?
>>>> this *must* be int (32bit!).
>>> I see no good reason to use short here, either.
>>> But I have to admit I am now curious-- what problem would it cause in
>>> this specific case? The number of args to the object will certainly be
>>> within the range of short, no?
>> I think because Pd doesn't know how any particular 'new' routine is
>> declared, it just passes the parameters the same way for every
>> object's 'new'.
> That means it's guaranteed to pass an int argc. As long as it's within
> short's range C should be able to shave it into a short, right?
The parameters are passed on the stack, so if it's a little-endian
machine the first two bytes will be the same for a short as for an int.
(Big-endians would think argc was zero). The problem arises when the
called routine looks for the first argv which it expects to find right
after the short argc on the stack. The caller put a four-byte int there
so the next two bytes will be zero and all the pointers to the argvs
will be wrong.
More information about the Pd-list