search

CMakePP / CMakePPLang

Object-oriented extension to the CMake language.
http://cmakepp.github.io/CMakePPLang/
Apache License 2.0
11 stars 4 forks source link

cpp_call_fxn does not re-escape quotes within its arguments #52

Closed AutonomicPerfectionist closed 2 years ago

AutonomicPerfectionist commented 2 years ago

Describe the bug When a string containing escaped quotes is passed as an argument to cpp_call_fxn() the quotes are unescaped, usually resulting in a syntax warning from CMake complaining the argument is not separated by whitespace, because the de-escaped quote closes the exterior quotes. However, if the previously-escaped quotes are not balanced, then it results in a full crash because the exterior quotes are no longer balanced.

This can most easily be seen by using exceptions.

To Reproduce Steps to reproduce the behavior:

  1. Create a CMake file with the following content: 
    
include(cmake_test/cmake_test)

cpp_catch(TEST_EXCEPTION) function("${TEST_EXCEPTION}" message) message("This does not execute") endfunction() cpp_raise(TEST_EXCEPTION "\"test")

2. Execute said file via cmake
3. Observe crash
4. Generated fxn call file is similar to the following:
```cmake
cpp_j92ue_1650743117(""test" )

Note the unbalanced exterior quotes.

Expected behavior All escape sequences should be passed through to the called function unmodified, and should not cause a crash or warning when including escaped quotes.

Additional context I am not sure if this would work but the first thing that comes to my mind is to modify cpp_call_fxn() to replace all \ with \\, so the slash is double escaped and properly written to the execution file. Alternatively, the newly-added cmake_language() command might be able to handle everything we need on its own

zachcran commented 2 years ago

I fixed a similar unescaping of escaped special characters during object method calls in #47. That solution requires a call to cpp_encode_special_chars(${ARGN} _encoded_args) directly inside the function call to protect special characters, along with the already existing call to cpp_decode_special_chars("${_cfg_args_list}" _cfg_decoded_args) in call_fxn.cmake at L27.

I think we could call cpp_encode_special_chars() at the top of cpp_call_fxn() to solve this issue. Arguments coming from object methods will already be encoded, so they are unaffected by the extra call, and arguments coming from a direct call to cpp_call_fxn() will be encoded. I'll give it a shot and submit a PR if it works.

ryanmrichard commented 2 years ago

@AutonomicPerfectionist feel free to reopen this if #53 didn't actually fix it.