break in for loop fails to compile with "Out of context"

[alank2]

Using:
zcc +cpm -DAMALLOC -O3 %1 -m --opt-code-speed=inlineints pfile.c sfile.c stfile.c unit1.c -o1.com

Output:
unit1.c:20:12: error: Out of context

Code: Select all

void changeext(char *APath, char *AExt)
{
  int i1;

  //go the end and search in reverse for ., :, /, or \\
  for (i1=strlen(APath)-1; i1!=-1; i1--)
    if (APath[i1]=='.' || APath[i1]==':' || APath[i1]=='/' || APath[i1]=='\\')
      break;
  
  //remove old extension if found
  if (i1!=-1 && APath[i1]=='.')
    APath[i1]=0;

  //add new extension
  strcat(APath, AExt);
}

The break; statement is the issue in the for loop. If I replace it with "goto exitloop;" and put an exitloop label beneath it, it will compile.

[dom]

Oh this is a nice gotcha.

Load the file into a syntax highlighting editor and you'll spot it straightaway.

Code: Select all

  //go the end and search in reverse for ., :, /, or \\

Your comment line ends in a \ so the following for line becomes part of the comment. As a result the break isn't in a for loop!

[alank2]

Interesting. When I try that in C++Builder I get a warning
Continuation character found in // comment

Which goes away if I use \\ instead of \

That is what I get for trying to comment it! I swapped it around to:
//go the end and search in reverse for ., :, \, or /

Thanks dom!

[Timmy]

Or you could just add a empty space at the end of your line. Or reorder your list.

To be honest it's always tricky how the parser would react, as the language the parser accept is Small-C, and not C++.

I still put an empty line at the end of each file, for example. I don't know if that problem has been solved or not (but it doesn't matter really).

[alank2]

I guess I should be thankful that it supports // in the first place!

I just reordered them.

[dom]

Just for the record, the continuation is handled by the preprocessor and the exact same behaviour occurs with clang.

[Timmy]

Yes, I've looked up on the preprocessor handling earlier, and this is indeed intended behaviour for C99 as well.

Which is completely logical to me, because the alternate way would be too inefficient for preprocessors back in the day.