[PD-dev] "int argc" giving weird values
IOhannes m zmölnig
zmoelnig at iem.at
Wed Mar 3 15:45:20 CET 2021
On 3/3/21 12:12 PM, Alexandre Torres Porres wrote:
> Em qua., 3 de mar. de 2021 às 07:26, IOhannes m zmoelnig <zmoelnig at iem.at>
>> what's that `t_pd*dummy` supposed to do in the argument list of `del_new`?
> no idea, I was trying to copy the structure from x_list.c, it was killing
> me that it works that but I'm obviously missing something.
well, "list" is a very special symbol in Pd.
that's why it requires special handling when using it as an object-name.
hence the "t_pd*dummy" hack in x_list.c
(btw, that's also the reason why zexy's [l] object (aka [lister]) has
such a stupid (long) name - i just couldn't make it work in a sane way
with the proper name "list". a good thing this is now, that Pd has a
[list] object which is slightly incompatible).
> It seems that's not what I have to do either. I copied the structure from
> x_array.c now and it just doesn't have any t_pd*dummy - other than me ;)
[array] is not a special symbol. that's why it is a working template for
any such code.
> funny that it was all working just fine, it was when I tried to add "flags"
> and parse them that things got weird...
i doubt it (that is: iff you also had any arguments)
having that extra "t_pd*" argument shifts the argument-list by 4 bytes,
making the values invalid.
usually this gets caught by the compiler.
however, since the constructor-functions arguments are established at
run-time (as opposed to compile-time), the code of Pd and friends is
full of function-casting, which very efficiently hides such problems.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 840 bytes
Desc: OpenPGP digital signature
More information about the Pd-dev