Re: [PATCH v11 2/4] x86/cpu: Check if feature string is non-zero

[Maciej Wieczor-Retman]

On 2026-03-23 at 17:23:24 +0100, Borislav Petkov wrote:
>On Mon, Mar 23, 2026 at 03:52:04PM +0000, Maciej Wieczor-Retman wrote:
>> It could be a problem if another entry is added that doesn't have the string
>> specified? Other spots that return either the string or the word:bit format do
>> check before if (!x86_cap_name[x]) isn't true. Is it not checked here on
>> purpose? Or is cpuid_dependent_features[] not expected to grow in the future?
>
>Yes, maybe, no...
>
>The point is, when you write commit messages, you should *precisely* explain
>what the issue or the non-issue is. What you have now is misleading - it
>should say what you just wrote above - that this could *potentially* be
>a problem but it isn't a problem now.

Okay, you're right, that could've been misleading, I'll rewrite that paragraph.

>> Right, sorry. Perhaps setting it to 24 would make sense? I think the longest
>> right now is 19, So there'd be some extra space in case a longer string is added
>> later?
>
>The use being?
>
>Nothing's stopping someone from slapping a longer name in "" in cpufeatures.h
>
>As long as you select a size and you enforce it somewhere and scream loudly
>when someone overflows it, then that's good. Otherwise what's the point of
>calling it anything if it is not being enforced?

Ah sorry, it's a bit of a misunderstanding, the X86_CAP_BUF_SIZE refers only to
the value that's needed for a buffer when the word:bit format is returned.
Otherwise the const char * is returned from the x86_cap_flags[] array.

So I guess the constant name should be different? Maybe X86_CAP_NUM_BUF_SIZE?


-- 
Kind regards
Maciej Wieczór-Retman