MantisBT - CMake
View Issue Details
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
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2007-10-31 12:54Josef KarthauserNote Added: 0009593
2007-10-31 13:55Brandon Van EveryNote Added: 0009595
2007-12-14 09:22Bill HoffmanNote Added: 0009876
2007-12-14 09:23Bill HoffmanNote Added: 0009877
2007-12-14 09:23Bill HoffmanStatusassigned => closed
2007-12-14 09:23Bill HoffmanResolutionopen => won't fix

Notes
(0009593)
Josef Karthauser   
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   
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   
2007-12-14 09:22   
I think the new functions should fix this.
(0009877)
Bill Hoffman   
2007-12-14 09:23   
I don't think this can be changed in macros for one thing it would break backwards compatibility.