Question

We are currently developing an application for a msp430 MCU, and are running into some weird problems. We discovered that declaring arrays withing a scope after declaration of “normal” variables, sometimes causes what seems to be undefined behavior. Like this:

foo(int a, int *b);

int main(void)
{
    int x = 2;
    int arr[5];

    foo(x, arr);

    return 0;
}

foo is passed a pointer as the second variable, that sometimes does not point to the arr array. We verify this by single stepping through the program, and see that the value of the arr array-as-a-pointer variable in the main scope is not the same as the value of the b pointer variable in the foo scope. And no, this is not really reproduceable, we have just observed this behavior once in a while.

This is observable even before a single line of the foo function is executed, the passed pointer parameter (b) is simply not pointing to the address that arr is.

Changing the example seems to solve the problem, like this:

foo(int a, int *b);

int main(void)
{
    int arr[5];
    int x = 2;

    foo(x, arr);

    return 0;
}

Does anybody have any input or hints as to why we experience this behavior? Or similar experiences? The MSP430 programming guide specifies that code should conform to the ANSI C89 spec. and so I was wondering if it says that arrays has to be declared before non-array variables?

Any input on this would be appreciated.

Update

@Adam Shiemke and tomlogic:

I’m wondering what C89 specifies about different ways of initializing values within declarations. Are you allowed to write something like:

int bar(void)
{
    int x = 2;
    int y;

    foo(x);
}

And if so, what about:

int bar(int z)
{
    int x = z;
    int y;

    foo(x);
}

Is that allowed? I assume the following must be illegal C89:

int bar(void)
{
    int x = baz();
    int y;

    foo(x);
}

Thanks in advance.

Update 2
Problem solved. Basically we where disabling interrupts before calling the function (foo) and after declarations of variables. We where able to reproduce the problem in a simple example, and the solution seems to be to add a _NOP() statement after the disable interrupt call.

If anybody is interested I can post the complete example reproducing the problem, and the fix?

Thanks for all the input on this.

Answer 1

You should be able to determine if it is a compiler bug based on the assembly code that is produced. Is the assembly different when you change the order of the variable declarations? If your debugger allows you, try single stepping through the assembly.

If you do find a compiler bug, also, check your optimization. I have seen bugs like this introduced by the optimizer.