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