Extension hide refactor; restore "strncpy" function alternatives #2817
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Requirements
BTT or MKS TFT.
Description
The author of that PR probably missed that the source string also contains the '\0' terminal character and the "strxcpy" copies only "num - 1" characters. So if the source is a filename (not a folder name) "num" equals to the number of bytes in the filename (excepting the '\0' terminal character) plus two more bytes (num = strlen(filename) + 2). If you substract 1 for "num" (becasue "num - 1" bytes will copy "strxcpy" from source to destination) you will end up to copy "num - 1" bytes from source which equals to "strlen(filename) + 1" which equals to the bytes number in the filename plus the '\0' terminator character. No risk of any overflow here.
So not only that "strxcpy" is PERFECTLY SAFE and suitable for the job in VFS API but it is also faster compared to the offered alternative by PR Bug fixes on top of last merged PRs #2768. This also adds to the snappiness of the filelist.
The alternatives offered by PR Bug fixes on top of last merged PRs #2768 are not as light as the ones they replaced and in some cases they fail to deliver the promised <"dest" always ends with '\0'> which results in an undefined/unsafe state of "dest" if it is not initialized beforehead. It's not the case with the functions of this PR.
Before checking if the firmware of the motherboard if it is Marlin or not there's a conditional if (levelStateNew != UNDEFINED) which limits the firmware to be either Marlin or Reprap. So if it's not Reprap, it's... you guessed right, it's Marlin! The fix of PR Bug fixes on top of last merged PRs #2768 was not a fix so it's reverted.