I have a few #if compiler options in my code to handle some if-else branching depending on the options for a protocol stack.
When using the IDE to perform brace matching to identify blocks, the non-compiled branch (e.g., #else branch) has the brace matching mechanism jump to that area, instead of the actually active code. As such, brace matching past the compiled-out code becomes out-of-sync (code may be okay, this could just be an IDE issue--to be verified).
Please referring to this example, where SNAP_NUM_PREAMBLE_BYTES is 1 (> 0), meaning that the #else case here is not included in the resulting code and is greyed out. However, brace matching ignores th greyed-out section and matches to the first brace found, rather than the actual brace that gets compiled in. This results in brace mismatch for statements above the #else statement due to the mismatch.
#if ( SNAP_NUM_PREAMBLE_BYTES > 0 )
if ( rxChar == SNAP_PREAMBLE_BYTE ) {
info_p->preamble_start = true;
info_p->preamble_count++;
}
else if ( rxChar == SNAP_SYNC_BYTE ) {
#else
if ( rxChar == SNAP_SYNC_BYTE ) {
#endif
// sync byte code
#if ( SNAP_NUM_PREAMBLE_BYTES > 0 )
// check preamble type
switch ( info_p->preamble_type ) {
case SNAP_PREAMBLE_NONE:
info_p->rx_frame_state = SNAP_RXFS_HDR2;
break;
case SNAP_PREAMBLE_RELAXED:
if ( info_p->preamble_count == 0 ) {
info_p->fault_type = SNAP_FAULT_BAD_PREAMBLE;
info_p->rx_frame_state = SNAP_RXFS_PROCESS_FAULT;
redo_flag = true;
}
else {
info_p->rx_frame_state = SNAP_RXFS_HDR2;
}
break;
<< ... >>
I haven't checked the resulting code but believe the code is likely okay--this bug appears to just be an IDE brace matching issue. I get no compiler problems with my code; this is just a coding/debugging/visualization issue.