This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Help : File does not end with newline


Frank Klemm wrote:-

> You have a mult-line macro in Windows:
> 
> 
> #define MULTI_LINE_MACRO	"This is a " \
> 				"multi-line macro"
> 
> The standard says:
> 
>          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.
>              If, as a result, a character sequence that matches the
>              syntax  of a universal character name is produced, the
>              behavior is undefined.  Only the last backslash on any
>              physical  source line shall be eligible for being part
>              of such a splice.  A source file  that  is  not  empty
>              shall  end in a new-line character, which shall not be
>              immediately preceded by a backslash  character  before
>              any such splicing takes place.
> 

The wording of phase 1 in C99 gives you leeway to interpret "new-line"
as you see fit.  So GCC 3.0 does so.

> but in Unix you see the following:
> 
> #define MULTI_LINE_MACRO	"This is a " \^M
> 				"multi-line macro"^M
> 
> 
> which disables the \^J deleting and result in a fatal error.

GCC 3.0 works with either form, please read the manual.

> Also from the
> view of a programmer this causes "invisible" trouble from time to time
> 
> #define MULTI_LINE_MACRO	"This is a " \ <-
> 				"multi-line macro"<-
> 
> "<-" is a mark which a lot of editors can insert to show trailing spaces and
> tabs.

GCC 3.0 works here too.  It accepts any of space, tab, vertical tab
and form feed.  Maybe you should try it 8-)

> Normally you don't see these ghosts. Both are problems which can be
> eliminated by changing the standard to:
> 
> 
>          2.  Each instance of a backslash character (\), followed by
>              optional white spaces and then immediately followed by a
>              new-line character is deleted, splicing physical source lines
>              to form logical source lines.  If, as a result, a character
>              sequence that matches the syntax of a universal character name
>              is produced, the behavior is undefined.  Only the last
>              backslash on any physical source line shall be eligible for
>              being part of such a splice.  A source file that is not empty
>              shall end in a new-line character, which shall not be
>              immediately preceded by a backslash character before any such
>              splicing takes place.
> 
> This is only a small change, a lot of compilers (IMHO gcc too) work in this
> way and the problem is known for more than 13 years for me.

No, GCC no longer falls over for these cases.

As for it being small change, that depends on the code.  In cpplib it
was a small change because the code to handle newlines is in just one
location.  tradcpp does not handle these issues, and if you think
fixing tradcpp is a small change I'd welcome your small patch 8-) 8-)

Neil.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]