Hi,
On 9-Nov-24 5:30 AM, Andy Shevchenko wrote:
> On Sat, Nov 9, 2024 at 1:24 AM Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
>>
>> Some enum style power-supply properties have text-values / labels for some
>> of the enum values containing a space, e.g. "Long Life" for
>> POWER_SUPPLY_CHARGE_TYPE_LONGLIFE.
>>
>> Make power_supply_show_enum_with_available() replace these spaces with
>> '_' when showing the available text-values. After this the output for
>> a battery which supports "Long Life" will be e.g.:
>>
>> Fast [Standard] Long_Life
>>
>> or:
>>
>> Fast Standard [Long_Life]
>>
>> Modify power_supply_store_property() to accept both the original text-value
>> with space and the alternative value with the spaces replaced by '_'.
>> This allows users to write the value with '_' after seeing this on reading
>> the property.
>
> ...
>
>> +static void power_supply_escape_spaces(const char *str, char *buf, size_t bufsize)
>> +{
>> + strscpy(buf, str, bufsize);
>> + strreplace(buf, ' ', '_');
>> +}
>
> The bufsize in all cases here is sizeof(buf), making the above to be a
> macro we may switch to 2-argument strscpy(). FTR, it embeds the check
> that buf is an array.
I did think about this already, but using a macro makes this harder
to read just to save 2 sizeof() calls. So I prefer doing things
this way.
>
> ...
>
>> + char escaped_label[32];
>
> Even more, the but size seems also the same, can we have buf defined
> inside the above?
No not really, its address would need to be returned then, requiring
it to be static, at which point we get race conditions when multiple
threads use the same function at the same time.
Regards,
Hans
