View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0005389 | CMake | CMake | public | 2007-07-23 16:13 | 2007-12-14 09:23 | ||||
Reporter | Brandon Van Every | ||||||||
Assigned To | Bill Hoffman | ||||||||
Priority | normal | Severity | major | Reproducibility | always | ||||
Status | closed | Resolution | won't fix | ||||||
Platform | OS | OS Version | |||||||
Product Version | |||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0005389: MACRO consumes double escapes in string arguments | ||||||||
Description | This 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 | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Relationships | |
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. |
Notes |
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 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |