This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C6000-CGT: CGT 8.3.7 - Abnormal behavior on assigning double value to a pointer

Part Number: C6000-CGT

I found a strange behavior when I assigned a double value to a memory allocated as unsigned integer. The double data corrupts the memory before the allocated address.

Sample code of my program

//Function to allocate memory – Returns the address
void allocate_memory(unsigned int **ppu32DataAddr, unsigned int u32Length)

double gdbData;
double *gpdbDataAddr;

int main(void)
{
    //5.123 - 0x40147DF3 B645A1CB (Double representation)

    /*****************************************************
    //Expected Results
    *****************************************************/
    //Address of gdbData is 0x00813300
    //0x00813300 is assigned 0xB645A1CB
    //0x00813304 is assigned 0x40147DF3
    gdbData         = 5.123

    /*****************************************************
    //Unexpected Results
    *****************************************************/
    //gpdbDataAddr points to 0x00812FEC
    allocate_memory((unsigned int **)&gpdbDataAddr, 2);

    //0x00812FE8 is assigned 0xB645A1CB-Corrupts the previous memory location
    //0x00812FEC is assigned 0x40147DF3
    *gpdbDataAddr   = 5.123;
}

  • Satya, A double must be aligned to a 64-bit address. Your integer pointer allocation routine aligns only to 32bit, the store instruction must be masking off the low address bits - hence 0x...EC becomes 0x...E8

  • The reply by Joe Josn is correct.  The compiler presumes that gpdbDataAddr contains an address that is aligned to an 8-byte boundary, but it is only aligned to a 4-byte boundary.  

    I am not familiar with the function allocate_memory.  I can tell you that malloc, and associated functions, in the compiler RTS library always returns an address that aligned to an 8-byte boundary, precisely to avoid this problem.

    Thanks and regards,

    -George