• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 54 subscribers
  • Views 2695 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Preprocessor mishandles whitespaces in multi-line macros

Aaron Steiner
Prodigy 190 points


I am using CCS V4, microcontroller edition, and I just spent a day and a half trying to figure out why I was unable to compile a bunch of multi-line macros. It turns out that the preprocessor can't handle whitespace after the " \ " character used to indicate the macro continues onto the next line. Some examples:

This will compile fine:

#define xPortSetupA0(ulWantedBaud)                                  \
{                                                                   \
unsigned portLONG ulBaudRateCount;                                  \
                                                                    \
    ulBaudRateCount = configCPU_CLOCK_HZ / ulWantedBaud;            \
    UCA0BR0 = ulBaudRateCount;                                      \
    /*       UCA0TXD select          */                             \
    /*       |      UCA0RXD select   */                             \
    /*       |      |                */                             \
    P3SEL |= BIT4 | BIT5;                                           \
    /*          UCSSELx = SMCLK      */                             \
    /*          |                    */                             \
}

This will not:

#define xPortSetupA0(ulWantedBaud)                                  \
{                                                                   \
unsigned portLONG ulBaudRateCount;                                  \
                                                                    \
    ulBaudRateCount = configCPU_CLOCK_HZ / ulWantedBaud;            \   
    UCA0BR0 = ulBaudRateCount;                                      \
    /*       UCA0TXD select          */                             \
    /*       |      UCA0RXD select   */                             \
    /*       |      |                */                             \
    P3SEL |= BIT4 | BIT5;                                           \
    /*          UCSSELx = SMCLK      */                             \
    /*          |                    */                             \
}

The only difference between the two code snippets is that there is a tab after the 5th line of code in the macro function (highlighted above).

I understand not allowing printed characters after the " \ " but mishandling whitespace seems like a bit of a stretch and something that should be fixed if possible.

  • 0
    TI__Expert 4930 points

    Well, the backslash exists to quote the carriage-return at the end of the line, to force the whole definition to be on one line as is required for #define.  By having whitespace after the backslash, you've allowed the return to be interpreted as a normal line break.

    Hunting through google results, I see some gcc documentation that says, "If there is white space between a backslash and the end of a line, that is still a continued line. However, as this is usually the result of an editing mistake, and many compilers will not accept it as a continued line, GCC will warn you about it."

  • 0 in reply to pf
    Prodigy 190 points

    pf, thanks for your reply. I see what you mean about how the compiler/preprocessor is interpreting the whitespace.

    So I guess what would be nice to have then is for the TI compiler to provide the same sort of warning when whitespaces are present between the backslash and the carriage return, but I suppose it would be difficult to distinguish between a valid line-break following a "\<SP>" or "\<TB> and someone making the kind of editing mistake I did.

    From a utilitarian perspective I think it is better to throw a warning when someone is doing something like this on purpose rather than generating an error that can be very tricky to debug because you have a non-printed character before the carriage return.