Fixed validation of full (absolute) filename#910
Conversation
|
|
||
| disk->Open(filepath); | ||
| if (!disk->FileExists(filepath)) { | ||
| return context.ReturnLocalizedError(LocalizationKey::ERROR_FILE_OPEN, initial_filename); |
There was a problem hiding this comment.
Should we remove the e.get_msg() argument from the ReturnLocalizedError call on line 589 below? Since you changed the error string to only take one positional string.
There was a problem hiding this comment.
@rdmark You are right, I missed that. Wouldn't have done harm, but is wrong. Just fixed it.
|
@rdmark I stumbled upon this as part of simplifying the filename handling as part of #722 (for the next release). Currently it is quite complicated due to the use of legacy classes instead of the standard C++ string class. |
|
@uweseimet So if the purpose here is to enable future improvements, shall we wait until after the release to merge this code? |
|
@rdmark No, because this is a bug (compared with 22.08.01), not just an improvement. Otherwise I would not have raised this PR, because currently I only create PRs for bugs that would affect the next release. |
|
I understand your intentions now. The change seems reasonable so I'll accept and let you merge when ready. |
|
@rdmark OK. In case another change is needed I will commit and then ask again for explicit approval. If no other change is required (further testing of the new code has not yet revealed anything new) I will merge tomorrow or so. I case you need the merge earlier, just go ahead. |
|
Fixed a missing CR/LF in the rasctl output. Before: After: |
|
Kudos, SonarCloud Quality Gate passed! |
|
@rdmark No further issues so far, except for the fixed typo in the previous commit. |
|
@uweseimet That's great. I suggest we merge this PR today, and then call an informal code freeze until the release is tagged this weekend. What do you think? |
|
@rdmark I thought we already had a code freeze, execpt for bug fixes. Anyway, I will merge soon. |








No description provided.