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: Multi line string literals are deprecated considered bad


On Mon, Mar 19, 2001 at 06:06:42PM +0100, Andi Kleen wrote:
> (although I guess the state tracking in the lexer would be a bit more
> complicated than you think. There can be keywords between asm and the
> opening brace, and inside the braces there can be statement expressions
> and other nasty things which make it impossible to search for ';' as 
> delimeter. The lexer would need to keep track of brace nesting)  

After thinking a bit more about the problem I think the following heuristic
in the scanner could work reasonably: 

if (seen asm keyword)  asm flag = 1;
if (asm flag) { 
	if (seen ':')  asm flag = 0; 
	if (seen string literal and next token is not another string literal) { 
		asm flag = 0; 
	} 
} 
if (seen multiline string and asm flag is not set) 
	warn multiline is deprecated.

Rationale: 
Multi line strings are only interesting for the first string in an assembler
statement. Although strings are allowed and needed for later expressions
(after the ":") multiline strings don't make much sense there anymore because
no long strings are needed. In the first string there is no expression 
allowed, so the problems with statement expressions do not occur. This 
means after all possible concatenated string literals after an asm keyword
have be seen the no warning mode could be turned off.
Special case is when the user writes no string before the first ':', e.g.
when the asm is only used as a memory barrier. This can be handled by turning
off the warning mode when the first ':' is seen after asm. 
Another case is empty asm(), but that's already illegal in the gcc grammer
and currently results in a syntax error.

I admit that this hack makes the specification of this to the user a bit ugly,
but I did not come up with a better way that does not require pushing the
multiline string warning check up to the parser (pushing it into the parser
would actually be the cleanest way) 

Comments? 


-Andi


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