Norcroft preprocessor line continuation char 'misplaced'

Non-native sources love to use multiline macros with the \ line continuation character. Norcroft gets most unhappy about this and can produce dozens or hundreds of errors as in

210  Serious error  misplaced preprocessor character '\'

Deleting the chars \ and making one very long line then compiles. It is a pain having to do this multiple times in each 1 of maybe 20 header files, and some source files as well, even using help from S & R.

Is there a way around this?

Just out of interest, what is the line termination on these files?

Just wondering if the compiler is seeing “backslash, whitespace, newline” because of CRLF termination, and thus faulting it because the backslash must be the last thing on a line.

Had a quick look. Line terminations are 0×20 0×5c 0×0a, so nothing that would get RISC OS in a tizz.

Just for the record, here is an example of a macro.

#define TRACEMS8(cinfo,lvl,code,p1,p2,p3,p4,p5,p6,p7,p8)  \
  MAKESTMT(int * _mp = (cinfo)->err->msg_parm.i; \
   _mp[0] = (p1); _mp[1] = (p2); _mp[2] = (p3); _mp[3] = (p4); \
   _mp[4] = (p5); _mp[5] = (p6); _mp[6] = (p7); _mp[7] = (p8); \
   (cinfo)->err->msg_code = (code); \
   (*(cinfo)->err->emit_message) ((j_common_ptr) (cinfo), (lvl)); )

The line feed is followed by a tab character, but surely that doesn’t screw things up!
Some macros have more lines than the above example, so the concatenated lines resulting from removal of \ and LF can get rather long, but the preprocessor doesn’t seem to mind that.

Admittedly, I’m not on the latest DDE, but I’ve got loads of \ in the Doom source.
Might be possible to try something simple and see if that’s ok before moving on to the complex stuff like that.

try something simple and see if that’s ok before moving on to the complex stuff like that.

Well, yes, but this source is already in existence.

I bet there are some spaces after one of the line continuation characters. I have a good number of multi-line macros that have always worked.

this source is already in existence.

I realised that from the reference to “Non-native sources”.

The point is to prove that \ does work, and then to find the problem with the lines given.
Once you know that, it’ll make correcting it easier. Especially as Stuart and Rick are probably both correct in that there is a extra space on the end of one of the lines.

I bet there are some spaces after one of the line continuation characters.

OK. I’ll have another look.

spaces after one of the line continuation characters

No – that is not the problem. An S & R in Zap, looking for \\\n, which finds backslash followed by LF, and replacing with nothing, sorted things in each source file, so there were not spaces at the end of lines.

I’ll have a play around with my own software to see if I can generate the error(s).

I’ve had this with non native files which have CR LF endings. The compiler is expecting \<LF> and not \<CR><LF>.

Editors such as !Zap will show (DOS) in the title bar for such files, and has an option to convert the endings in the save options menu.

Editors such as !Zap will show (DOS) in the title bar for such files, and has an option to convert the endings in the save options menu.

It actually shows an upper case D.

Thank you David. Zap is too clever by halves. When you view the file in Zap in byte mode it shows only LF. However, if you load the file in to good old !Edit, lo and behold it shows the presence of CR as well as LF.

Doh!