Interface parameters assigned in reverse order

[mszczodrak]

The following describes a semantic bug found in the latest version of nesc.

When a module provides a parameterized interface, with more than one parameter on the interface, the parameters in the function implementing the interface come in the reversed order.

For example, we are wiring to a module TestC implementing interface Test.

 BlinkC.Test -> TestC.Test[10, 20, 30];

then TestC provides interface as follows:

 provides interface Test[uint8_t par1, uint8_t par2, uint8_t par3];

and implements interface function bug():

    command void Test.bug[uint8_t par1, uint8_t par2, uint8_t par3]() {
            printf("Receive Parameters %d %d %d\n", par1, par2, par3);
            printfflush();
    }

At run time, we observe the following serial print output:

Receive Parameters 30 20 10
Receive Parameters 30 20 10
Receive Parameters 30 20 10
...

Parameters arrive in the reverse order (should be 10, 20, 30).

This bug can have a compile-time error, when the parameter values are heterogeneous. If we expect parameters, [uint8, uint8, uint16] and assign values [10, 20, 300] then we get

   'constant out of range for argument type'

because 300 is assigned to the first parameter of type uint8_t.

A sample test code has been uploaded to: http://www.cs.columbia.edu/~msz/wsn/nesc_interface_params/
The test code is configured for the TOSv3, tested on the latest tinyos-main branch, on telosB.