nnorwitz@users.sourceforge.net wrote:
Need to make sure that preprocessor directives start in first column. This means we can't indent code which has preprocessor directives, nor have a space between [ #include for example.
What does the C standard say about this? I'm curious.
Neil
[from a checkin comment]
Need to make sure that preprocessor directives start in first column. This means we can't indent code which has preprocessor directives, nor have a space between [ #include for example.
[Neil Schemenauer]
What does the C standard say about this? I'm curious.
Spaces and horizontal tabs are fine before '#', and between '#' and the directive name; other kinds of whitespace are not OK in directive lines (and directive lines are special this way); sounds like we're catering to a broken compiler here.
On Sun, Feb 23, 2003 at 10:29:59PM -0500, Tim Peters wrote:
[from a checkin comment]
Need to make sure that preprocessor directives start in first column. This means we can't indent code which has preprocessor directives, nor have a space between [ #include for example.
[Neil Schemenauer]
What does the C standard say about this? I'm curious.
Spaces and horizontal tabs are fine before '#', and between '#' and the directive name; other kinds of whitespace are not OK in directive lines (and directive lines are special this way); sounds like we're catering to a broken compiler here.
I always thought you could have whitespace between the '#' and the directive name, but not before the '#'. According to everything I read, you can have spaces before the '#', tabs are less clear. I didn't find any info about which standard they are referring to.
I've found some different answers:
http://www.opus1.com/vmsdoc/progtool/cpqc64/5492p033.htm
states: The ANSI C Standard removes the VAX C restriction that requires the # character introducing a preprocessor directive to always appear in column 1 of the source line. In Compaq C, white space and comments can now precede the # on the same line.
This: http://nimbus.pa.uky.edu/cfromfortran/preprocessor.htm states: All preprocessor directives begin with # as the very first non-space character. This is important - the first non-space character must be #, tabs will work with some implementations, but are not ANSI-compliant and will fail with others. Spaces can appear before the # in ANSI C.
Neal
On dinsdag, feb 25, 2003, at 22:16 Europe/Amsterdam, Neal Norwitz wrote:
On Sun, Feb 23, 2003 at 10:29:59PM -0500, Tim Peters wrote:
[from a checkin comment]
Need to make sure that preprocessor directives start in first column. This means we can't indent code which has preprocessor directives, nor have a space between [ #include for example.
[Neil Schemenauer]
What does the C standard say about this? I'm curious.
Spaces and horizontal tabs are fine before '#', and between '#' and the directive name; other kinds of whitespace are not OK in directive lines (and directive lines are special this way); sounds like we're catering to a broken compiler here.
Before ANSI C said it is okay to have whitespace before the # most compilers would require the # to be in column one. And I've seen quite a couple of sources that had something like #if __STDC__ #pragma or other ansi construct #endif -- - Jack Jansen Jack.Jansen@oratrix.com http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -
[Neal Norwitz]
I always thought you could have whitespace between the '#' and the directive name, but not before the '#'. According to everything I read, you can have spaces before the '#', tabs are less clear. I didn't find any info about which standard they are referring to.
The C standards aren't available for free, but the C99 standard is cheap. It's quite clear.
A preprocessing directive consists of a sequence of preprocessing tokens that begins with a # preprocessing token that (at the start of translation phase 4) is either the first character in the source file (optionally after white space containing no new-line characters) or that follows white space containing at least one new-line character, and is ended by the next new-line character. A new-line character ends the preprocessing directive even if it occurs within what would otherwise be an invocation of a function- like macro.
Later:
The only white-space characters that shall appear between preprocessing tokens within a preprocessing directive (from just after the introducing # preprocessing token through just before the terminating new-line character) are space and horizontal-tab (including spaces that have replaced comments or possibly other white-space characters in translation phase 3).
So you can actually have any whitespace characters before the #, but only space and tab after it.
I used to have a bootleg C89 standard on my drive, but can't seem to find it. I doubt it's different here, but don't know for sure. The C99 Rationale (not part of the C99 standard) says:
Different implementations have had different notions about whether white space is permissible before and/or after the # signalling a preprocessor line. The C89 Committee decided to allow any white space before the #, and horizontal white space (spaces or tabs) between the # and the directive, since the white space introduces no ambiguity, causes no particular processing problems, and allows maximum flexibility in coding style. Note that similar considerations apply for comments, which are reduced to white space early in the phases of translation.
This strongly implies that the same rules held in C89.
Neil Schemenauer wrote:
nnorwitz@users.sourceforge.net wrote:
Need to make sure that preprocessor directives start in first column. This means we can't indent code which has preprocessor directives, nor have a space between [ #include for example.
What does the C standard say about this? I'm curious.
No idea, but emacs mode is pretty clear on this: you don't get syntax highlighting when moving the # beyond column 1.
What I usually do is to indent the directive after the #:
#ifdef MX_BUILDING_MXDATETIME # define MXDATETIME_EXTERNALIZE MX_EXPORT #else # define MXDATETIME_EXTERNALIZE MX_IMPORT #endif