View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005389CMakeCMakepublic2007-07-23 16:132007-12-14 09:23
ReporterBrandon Van Every 
Assigned ToBill Hoffman 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0005389: MACRO consumes double escapes in string arguments
DescriptionThis is really bad for macros wrapping regular expressions, because result expressions of the form "\\\\1\\\\2\\\\3" are used all the time. We don't want to have to pass result expressions with twice as many escapes, like "\\\\\\\\1\\\\\\\\2\\\\\\\\3". It's error prone.

MESSAGE("Ordinarily, double escapes in strings work fine.")
MESSAGE("\\\\1\\\\2\\\\3")
SET(str123 "\\\\1\\\\2\\\\3")
MESSAGE("${str123}")

MESSAGE("MACRO consumes escapes, causing errors.")
MACRO(MUNGE str)
  MESSAGE("${str}")
ENDMACRO(MUNGE)
MUNGE("\\\\1\\\\2\\\\3")

C:\\devel\\src\\cbugs\\macro>cmake -P macro.cmake
Ordinarily, double escapes in strings work fine.
\\1\\2\\3
\\1\\2\\3
MACRO consumes escapes, causing errors.
CMake Error: Invalid escape sequence \\1
CMake Error: Syntax error in cmake code at
C:/devel/src/cbugs/macro/macro.cmake:10:
syntax error, unexpected cal_ERROR, expecting $end (2), when parsing string "\\1\\
2\\3"
\\1\\2\\3
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0009593)
Josef Karthauser (reporter)
2007-10-31 12:54

This is a really painful bug. It basically means that one can't write macros which are safe, if they are operating on arbitary input strings (obtained from a file for instance).

It ought to be fixed asap.
(0009595)
Brandon Van Every (reporter)
2007-10-31 13:55

A workaround is not to pass literal strings to macros. Instead pass them in variable names. So, the macro is safe if you know what you're doing... and dangerous if you don't.
(0009876)
Bill Hoffman (manager)
2007-12-14 09:22

I think the new functions should fix this.
(0009877)
Bill Hoffman (manager)
2007-12-14 09:23

I don't think this can be changed in macros for one thing it would break backwards compatibility.

 Issue History
Date Modified Username Field Change
2007-10-31 12:54 Josef Karthauser Note Added: 0009593
2007-10-31 13:55 Brandon Van Every Note Added: 0009595
2007-12-14 09:22 Bill Hoffman Note Added: 0009876
2007-12-14 09:23 Bill Hoffman Note Added: 0009877
2007-12-14 09:23 Bill Hoffman Status assigned => closed
2007-12-14 09:23 Bill Hoffman Resolution open => won't fix


Copyright © 2000 - 2018 MantisBT Team