Bug fix for registry path length checks when doing out-of-source code generation

[islas]

TYPE: bug fix

KEYWORDS: registry, path

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
PR #1975 added the ability for registry code to be generated out-of-source. To do this, a provided path is used and prepended to include statements within registry files. The max path length checks to create the search path string in a char* does not take into account the combined prepend path + relative file path length. When this happens, no obvious errors occur, but a buffer overflow causes malformed registry code to be used, eventually leading to failed compilation.

Solution:
Use a max path length that checks both the relative file path length and combined length when using the prepended path. As failure to pass this will result in erroneous code, the error messages have been updated to convey that as well.

TESTS CONDUCTED:

1. Tested with CMake build using an absolute path greater than ~128. Without these changes the registry code will pass but compilation will fail. With these changes, that path length works and paths > 256 will fail at the registry code generation step.

RELEASE NOTE: Bug fix for registry path length checks when doing out-of-source code generation

[weiwangncar]

The regression test results:

Test Type              | Expected  | Received |  Failed
= = = = = = = = = = = = = = = = = = = = = = = =  = = = =
Number of Tests        : 23           24
Number of Builds       : 60           57
Number of Simulations  : 158           150        0
Number of Comparisons  : 95           86        0

Failed Simulations are: 
None
Which comparisons are not bit-for-bit: 
None

[mgduda]

Was this print statement added for debugging purposes? If so, perhaps it could be removed.

[islas]

Thanks for the catch!

[mgduda]

For consistency with other messages throughout the registry tool, should we retain the "Registry warning:" text for now rather than "Registry error:"? A separate PR could be used to consistently change "warning" messages to "error" messages throughout the reg_parse.c code, and at that time, we could also decide whether to use the word "Error" (with a capital-e), as it seems like a lot of guidance to WRF users is to search for "Error" in the build log.

[islas]

I understand the sentiment, though I think there is something to be said for piecemeal improvements that don't significantly impact functionality while incomplete. I think this could fall under a reasonable clean-as-you-go improvement to better the message output to reflect the severity.

There isn't exactly a good precedent set by registry message prefixes both in style and actual severity. Given the lack of consistency in registry messages, I think it would be better to update messages to say what they actually mean whilst editing the relevant code rather than keeping consistent with the most used prefix to be fixed later.

The fix to update message prefixes should still happen, but I don't think that fix should preclude us from making incremental progress.

[islas]

@mgduda The failure mode was still implicit, so I've added return statements that end Registry processing when these errors are hit. This falls inline with the expected return of this function and the call chain handles it appropriately.

[dudhia]

I will approve this even though it is outside my scope. Is this just related to cmake? If so, the description should reflect that.