C preprocessor gotcha / unexpected behavior

[tlovern]

In my code comments, I will use "\" and "/" characters to indicate a comment applies to several lines of code:

Code: Select all

char a[1];		//  \
char b[1];		//   + these are silly examples
char c[1];		//  /

looks like the pre-processor sees the "\" and folds the next line into the comment,
any references to b, as in b[0] = 'a' will generate a compiler error showing b as undefined.

I have not experienced this behavior before, maybe I was just lucky?

shouldn't the pre-processor ignore stuff in comments?

I can adjust my coding to avoid this.

[arne_v]

C11 standard says:

Each instance of a backslash character (\) immediately followed by a new-line
character is deleted, splicing physical source lines to form logical source lines.

so I think it is expected behavior.

[tlovern]

Interesting, I'd expect it for source lines, not for comments. most everything else is ignored within the context of a comment or comment block.

Not a huge deal, just the first time I've been bit by this....

[arne_v]

The standard list order as:

5.1.1.2 Translation phases
1 The precedence among the syntax rules of translation is specified by the following
phases.
...
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.
...
3. The source file is decomposed into preprocessing tokens ... Each comment is replaced by
one space character. ...
...

I am no an expert in standards reading, but I read it as the backslashes are handled before comments are handled.

[jonesd]

Follow the backslash by a space and it doesn't consider it a continuation.

I too would have thought the // comment indicator would have considered everything until the next newline to be part of the comment.

[sms]

Code: Select all

> looks like the pre-processor sees the "\" and folds the next line into
> the comment,

   That's not "the next line"; it's a continuation of the _same_ line.

> I have not experienced this behavior before, maybe I was just lucky?

   Where did you get your experience?  A quick test on a Mac:

proa$ cc --version
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/
XcodeDefault.xctoolchain/usr/bin

proa$ cc bs.c
bs.c:9:3: error: use of undeclared identifier 'b'
  b[ 0] = a[ 0];
  ^
1 error generated.

   I seldom use fancy new features like "//", so my experience is
limited, but I didn't find that behavior amazing.


> Interesting, I'd expect it for source lines, [...]

   Define "source line".  (Or, apparently, "logical source line".)

Added in 5 hours 52 minutes 57 seconds:

Code: Select all

> [...] on a Mac:

   If you have access to a compiler with UNIX-typical command options,
then the results from "cc -E" might be educational/informative.  (This
is one case where I didn't find a VMS-style /LIST file especially
helpful.)

   Given that "\" is special, a scheme like the following might cause
less trouble:

      //  }
      //   }
      //   } + these are silly examples
      //   }
      //  }


> Follow the backslash by a space [...]

   Yup.  And who wouldn't always spot an accidentally absent trailing
space?

[tlovern]

Where'd I get my experience....really?

Define source line:

text I expect to become executable code, defined by line breaks designed to make the text readable by humans.

Non-source line:

text that is either comments or whitespace also defined by human readable lines, designated with line breaks.

Line break:

typically <CR><LF> pairs arranged in a sequence the OS likes.

lines, allow you to get LINE NUMBERS in listings, and goto specific LINES in editors...

but I digress...

I was compiling code that has run for years...as in originally on VAX, then Alpha, then Itanium, and now being ported to X86. Luckily, it's non-commercial stuff - so I can address it at my leisure.

it's possible I stripped trailing character(s) when I moved the code to the X86, as I had to clean up some artifacts from using FileZilla. I did the cleanup using some TPU code I wrote (way back when) for such purposes.

I'm just surprised this never popped up before now.

as far as the suggested alternatives, already done, including a search of the source code - it was found in maybe 3 other modules, now fixed.

It's just that when something used to work and now it doesn't, red flags go off. In this case, apparently the code had trailing spaces or tabs that got stripped off. And since nothing VISIBLY changed in the source code...

[sms]

Code: Select all

> Where'd I get my experience....really?

   Yes, "really".  With my weak psychic powers, I have no idea where
code like this might have worked.  VAC C V3.2-044 (the last VAX C, so
far as I know) doesn't support "//" (or "\").  I've tried a sample of
the VMS DEC C compilers available here with consistent results:

      DEC C V4.0-000 (the first DEC C, so far as I know) on VMS V5.5-2:

GIMP $ cc /decc bs.c
          b[ 0] = a[ 0];
        ..^
%CC-E-UNDECLARED, In this statement, b is not declared.
                At line number 9 in DUA1:[VSI]BS.C;2.
[...]


      Compaq C V6.4-005 on OpenVMS VAX V7.3:

wisp $ cc bs.c
          b[ 0] = a[ 0];
        ..^
%CC-E-UNDECLARED, In this statement, "b" is not declared.
                At line number 9 in WISP$DUA0:[SMS.VSI]BS.C;2.
[...]


      VSI C V7.4-001 on OpenVMS IA64 V8.4-2L3:

its $ cc bs.c

  b[ 0] = a[ 0];
..^
%CC-E-UNDECLARED, In this statement, "b" is not declared.
at line number 9 in file ITS$DKA0:[SMS.VSI]bs.c;2


      VSI C X7.4-785 (GEM 50X65) on OpenVMS x86_64 V9.2-1:

V87 $ cc bs.c

  b[ 0] = a[ 0];
..^
%CC-E-UNDECLARED, In this statement, "b" is not declared.
at line number 9 in file SYS$SYSROOT:[SYSMGR]bs.c;2


   All of which agree with the first non-VMS compiler I tried.

   So, yes, "really".


> Line break:
> 
> typically <CR><LF> pairs arranged in a sequence the OS likes.

   Apparently, your definition conflicts with the standard definition,
where "\" eliminates a new-line which follows it immediately.

> lines, allow you to get LINE NUMBERS in listings, and goto specific
> LINES in editors...

   As we've both been shown, the standard distinguishes between two
kinds of lines:

> [...] splicing physical source lines to form logical source lines.


> it's possible I stripped trailing character(s) [...]

   As I tried to suggest, relying on invisible characters to resolve
what would have been syntax errors is, at best, chancy.  I routinely
strip trailing white space from source files, and I'd guess that I'm not
alone in that, so a comment style like this looks to me like a booby
trap.

>  I'm just surprised this never popped up before now.

   After a brief search, I haven't found a compiler which works as you
claim to expect, so I can't explain that.

[tlovern]

I came across a little snarky, which wasn't my intent. Apologies to all who read my text.

The issue was that I cleaned up a header file and discovered behaviors I wasn't expecting. One of the things I did which introduced an unexpected side effect (to me) was the conversion of /* */ pairs to // in the header file.

who would have reasonably thought that comment style would introduce a problem?

As far as the whole source lines thing, that seemed a bit condescending to me and probably set me off a little more than it should have.

anyway, it's a non-issue and I learned something about the pre-processor I had not encountered before, meh, it happens.

I've used the "\" extensively in macro definitions. I never had an issue with it with old style comments, and would not expect a different behavior with text the compiler is supposed to ignore.

it's all good, got the code working, other than planned enhancements.

cheers.