1

This is related to Multi line preprocessor macros. I'm interested in the #if or #elif, and not the macro being defined. For example, is the following valid:

#if defined(X) || defined(Y) || \
    defined(Z)
...
#endif

The reason I'm asking is Clang, GCC and MSVC accept it, but some Sun tools on Solaris are complaining about it. GCC documents the behavior at 1.2 Initial processing ("backslash-newline" and "continued lines"), but Sun tools like DBX encounter an internal error.

Community
  • 1
  • 1
jww
  • 97,681
  • 90
  • 411
  • 885
  • 1
    Make sure there are no carriage returns at the ends of the lines (after the backslash, before the newline). Otherwise, there's no problem. You should identify which Sun tools have the problem. I've never seen a problem like that on any platform over a long period, but I've not done much on Solaris in the last five years or so, and things might have changed (but I don't think it likely). Note that backslash-newline parsing comes before the input is tokenized. You can split keywords with backslash-newline as long as there's no leading space on the next line. – Jonathan Leffler Apr 26 '17 at 03:23
  • @JonathanLeffler - There should be no whitespace after the backslash. Our makefile has a [recipe to trim trailing whitespace](https://github.com/weidai11/cryptopp/blob/master/GNUmakefile#L740), and other tools like GCC don't warn of extra whitespace. For an example of the error in Sun tools, see [Coredump in cryptest.exe on Solaris 10](https://groups.google.com/d/msg/cryptopp-users/OYaByDEbSI0/zrIjWUtEAQAJ). – jww Apr 26 '17 at 04:18
  • I used the Sun compiler more on Solaris 9 — running the result on Solaris 10 — but I've not worked with Solaris 11. (It always exasperated me that keeping up-to-date with the leading edge environments wasn't deemed important.) It puzzles that the compiler generates code that crashes when other compilers accept it; that sort of thing tends to be a show-stopper, or cause to switch to an alternative compiler. Sometimes, the trouble is undefined behaviour; presumably that isn't the problem in this code. I'm not clear that the problem is backslashes, but I've not studied the code in detail. – Jonathan Leffler Apr 26 '17 at 04:30
  • What are these Sun tools you speak of? Sun is dead... ;-) Assuming you're running Studio 12.5, what are the complaints? I've not seen such problems, but I don't recall now if I've actually used `dbx` under 12.5. – Andrew Henle Apr 26 '17 at 09:57

1 Answers1

6

They're valid, because the backslashes before newlines are removed in phase 2 before the preprocessing is done in phase 4.

Phase 2

  1. Whenever backslash appears at the end of a line (immediately followed by the newline character), both backslash and newline are deleted, combining two physical source lines into one logical source line. This is a single-pass operation: a line ending in two backslashes followed by an empty line does not combine three lines into one.

...

Phase 4

  1. Preprocessor is executed.

http://en.cppreference.com/w/c/language/translation_phases

phuclv
  • 37,963
  • 15
  • 156
  • 475
  • That's a C++ reference. The question is tagged C *and* C-preprocessor. – Andrew Henle Apr 26 '17 at 10:00
  • [The C Standard](http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf) reference is **5.1.1.2 Translation phases**, paragraph 2: "Each instance of a backslash character (\\) immediately followed by a new-line character is deleted, splicing physical source lines to form logical source lines." – Andrew Henle Apr 26 '17 at 10:17
  • 1
    @AndrewHenle thanks, I've just fixed the link and the quote – phuclv Apr 26 '17 at 10:54
  • Thanks @LưuVĩnhPhúc. I guess we are encountering a Solaris bug. – jww Jun 06 '17 at 04:32