[PD] arguments not passed to an external

[Jonathan Wilkes]

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?

> Also the c compiler doesn't know that the 'new' routine must take a 
> certain form, so you don't get any errors until it actually runs. 
> (this could probably be fixed with a typedef for a Pd 'new' routine)
> In the remote past, short and int were the same thing, but as 
> processors evolve, int gradually gets longer while short stays short.

But short isn't going to get shorter.  So how is a constructor that 
expects A_GIMME to have an argc of "2" going to get into trouble?

-Jonathan

>
> Martin
>
>