[PD] arguments not passed to an external
Martin Peach via Pd-list
pd-list at lists.iem.at
Tue May 27 17:19:07 CEST 2014
On 2014-05-27 04:00, Alexandros Drymonitis wrote:
> 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.
> Since my laptop's processor is an Intel Core 2, it's a little edian one,
> right? How can I make my code versatile so that it can compile on either
> little or big endian machines? I'm reading Pd's source code ([phasor~]'s
> code, for example) but it's beyond my understanding. I kind of
> understand the beginning of d_osc.c where the code will try to determine
> the endianess of the machine, but when it comes to sorting arguments out
> depending on the endianess, I'm at loss.
You don't need to know the endianness of the machine. The compiler and
linker take care of that. (You could use the htons() function on a test
short like 1234 to see if the result is the same as the input. If they
are the same then you have a big-endian machine.)
As long as you declare your 'new' routine with argc as an int it will
> Another important question I still have is, how do I determine whether
> there is a signal coming in the object's inlets, so I know whether to
> use the values passed via arguments, or the vectors passed from the dsp
> method. I'm asking the same thing over and over again...I'll stop for now.
I think if you get all zeros on the vector for the inlet you can assume
it's not connected. So use the argument values until you get non-zero on
the inlet vectors.
More information about the Pd-list