RFR: 8257800: CompileCommand TypedMethodOptionMatcher::parse_method_pattern() may over consume [v2]

[Xin Liu]

On Thu, 10 Dec 2020 00:29:42 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> I'm seeing failures in testing `test/jdk/com/sun/jdi/EATests.java`:
>> CompileCommand: An error occurred during parsing
>> Error: Did not specify any method name
>> Line: 'dontinline,*::dontinline_*'
>> 
>> Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true
>> Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>'
>> Use:   '-XX:CompileCommand=help' for more information and to list all option.
>
>> @TobiHartmann
>> thank you fore verifying that. it's a corner case. The valid form -XX:CompileCommand=dontinline,_::dontinline__ is treated as an error. the reason is that parse_option_name is a fuzzy matcher. it will match `dontinline` out of 'dontinline_*'.
>> 
>> now I change parse_option_name to an exact matcher. original parse_option_name is renamed to match_option_name.
>> 
>> Actually, there is still an edge case ` -XX:CompileCommand=dontinline,*::dontinline`, which is wrongly taken as an error.
>> I haven't found an easy fixer. Because the old form will be gone, I think this patch is just a temporary relief of the security loophole and will be deleted with the old form. so let it be.
> 
> I figure out a very easy way to fix the corner ` -XX:CompileCommand=dontinline,*::dontinline`. if it reaches the end of string, 
> just mark it's a valid method name.
> `        *(line + bytes_read) != '\0'
> `

may I ping this PR?  The existing failures are not from my change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1652