[PD] arguments not passed to an external

[Martin Peach]

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.

Martin