[PATCH 15/19] RISC-V: avoid buffer underrun in subset parsing

[Jiawei]

On 2026/5/4 16:10, Jan Beulich worte:
> On 29.04.2026 14:37, Jiawei wrote:
>>> In both instances 'p' can be the first character. Inspecting the character
>>> immediately ahead of it is then UB.
>>>
>>> To increase similarity between the two checks (each), also move the
>>> increment of q past the check for the (bogus) "<number>p" ending.
>>>
>>> Correct indentation in nearby code, where it being wrong is actively
>>> misleading.
>>> ---
>>> Why is it that P is recognized as an extension when there's no other
>>> support there for it?
>>>
>> LGTM.
>>
>>
>> Regarding the question about P, the P extension is still in draft state:
>>
>> https://github.com/riscv/riscv-p-spec
> I know.
>
>> We already have some downstream experimental support for it. Once the P
>> specification is frozen, we plan to prepare and submit the corresponding
>> binutils support upstream.
> Right, but my question was why there's partial support, resulting in
> potentially misleading behavior.
>
> Thanks for all the reviews, btw.
>
> Jan
Thanks for the clarification, Jan.

I see your point now.  I was thinking about the lack of full upstream P
support, but your concern is about the existing partial recognition in the
parser.

I agree that this can be misleading if P is accepted in the arch string 
while
there is no corresponding opcode/disassembler support.  Unless there is a
compatibility reason to keep recognizing it, removing it for now, or at 
least
diagnosing it more clearly as unsupported, sounds reasonable.

This is orthogonal to the buffer-underrun fix, but it is worth handling as a
separate cleanup.

Best regards,
Jiawei