[sv-bc] 1339: (RESEND)`define behavior on trimming leading and trailing spaces in macros

(Last mail had "strikethrough" turned on, so resending a legible version
of this).

 

I posted another proposal.  This one is for Mantis 1339.  Shalom gave me
a handful of proposals to work on, 1338 being one of them.  1339 was not
but it's on our final list and appears to be closely related so I hope
no one minds.

 

I agree with most of the comments made thus far on this proposal.  IMHO
we should eliminate leading and trailing white-spaces in macros.  We
should leave white-spaces alone everywhere else.  The only issue I could
think of with this proposal deals with escaped identifiers being
constructed off any of these spaces.  Hopefully the designer is smart
enough to know that should he attempt this, he must place his extra
spaces to delimit the identifier in the macro call.  

 

Here is the additional wording.  I took some of it from the ANSI C
preprocessing document that Steven pointed us to. I am not a wizard yet
on LRM word-smith'ing so any advice before we vote on this would be
welcome.

 

Thanks, -Tom 

 

The macro text can be any arbitrary text specified on the same line as
the text macro name. If more than one line is necessary to specify the
text, the newline shall be preceded by a backslash ( \ ). The first
newline not preceded by a backslash shall end the macro text. The
newline preceded by a backslash shall be replaced in the expanded macro
with a newline (but without the preceding backslash character).  Any
white-space characters preceding or following the macro replacement
string are not considered part of the replacement. Additionally, for
multi-line macros any trailing white-space between the last token on a
line and the newline before a backslash is not considered part of the
replacement. 

 

 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.