[PD] arguments not passed to an external
jancsika at yahoo.com
Tue May 27 02:30:08 CEST 2014
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?
More information about the Pd-list