| 10935 | |
| 10936 | |
| 10937 | ResultType Line::PerformLoopFilePattern(ResultToken *aResultToken, Line *&aJumpToLine, Line *aUntil |
| 10938 | , FileLoopModeType aFileLoopMode, bool aRecurseSubfolders, LPTSTR aFilePattern) |
| 10939 | { |
| 10940 | ResultType result = CONDITION_FALSE; |
| 10941 | // LoopFilesStruct is currently about 128KB, so it's probably best not to put it on the stack. |
| 10942 | // 128KB temporary usage per Loop (for all iterations) seems a reasonable trade-off for supporting |
| 10943 | // long paths while keeping code size minimal. |
| 10944 | LoopFilesStruct *plfs = new LoopFilesStruct; |
| 10945 | if (!plfs) |
| 10946 | return MemoryError(); |
| 10947 | // Parse aFilePattern into its components and copy into *plfs. Copies are taken because: |
| 10948 | // - As the lines of the loop are executed, the deref buffer (which is what aFilePattern might |
| 10949 | // point to if we were called from ExecUntil()) may be overwritten -- and we will need the path |
| 10950 | // string for every loop iteration. |
| 10951 | // - We relative paths resolved to full paths in case the working directory is changed after the |
| 10952 | // loop begins but before FindFirstFile() is called for a sub-directory. |
| 10953 | // - Several built-in variables rely on the paths stored in *plfs and updated on each iteration. |
| 10954 | // This approach means a little up-front work that mightn't be needed, but greatly improves |
| 10955 | // performance in some common cases, such as if A_LoopFileLongPath is used on each iteration. |
| 10956 | if (ParseLoopFilePattern(aFilePattern, *plfs, result)) |
| 10957 | result = PerformLoopFilePattern(aResultToken, aJumpToLine, aUntil, aFileLoopMode, aRecurseSubfolders, *plfs); |
| 10958 | //else: leave result == CONDITION_FALSE, since in effect, no files were found. |
| 10959 | delete plfs; |
| 10960 | return result; |
| 10961 | } |
| 10962 | |
| 10963 | |
| 10964 |
no test coverage detected