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 just work.
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.
Martin