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