> On Oct 4, 2017, at 7:22 PM, Ben Hutchings <ben.hutchi...@codethink.co.uk>
> wrote:
>
> On Tue, 2017-09-19 at 12:30 +0400, Ilya Matveychikov wrote:
>> Hi guys,
>>
>> Please review the approach of using small fixed-sized arrays to improve
>> parsing of values like get_options() does.
>>
>> This comes to me after fixing an overflow in get_options(). See the thread
>> for details: https://lkml.org/lkml/2017/5/22/581
>>
>> If the approach is OK I’ll suggest to replace all of get_options() calls
>> to ksa_parse_ints() and remove get_options() at all.
>
> You didn't cc the patches to me, and I can't find patch 3/3 at all.
Thanks for you answer. I posted them on list, except the last one as what I
wanted is to get the feedback first. I CC’d you as you found a problem with
my patch for get_options() before (read out of bounds).
>
> don't think the KSA() macro should be casting its argument. Where the
> cast is necessary, it ought to be explicit in the caller.
KSA(x) it’s just a simple way to cast from custom-defined small array
to generic one. Do you think that it’s better to use explicit casting:
ksa_parse_foo(..., (struct ksmall_array *)&my_custom_ksa)
Instead of:
ksa_parse_foo(..., KSA(&my_custom_ksa))
Not sure...
>
> Similarly I think the BUILD_BUG_ON() in ksa_build_check() doesn't belong
> there, but in whichever caller of ksa_parse_ints() requires struct
> ksmall_array to have the same layout as a simple array of unsigned int.
Not sure that I understand your point. The purpose of ksa_build_check() as
I wrote it is to to do compile-time check for sizeof(struct ksmall_array)
to fit sizeof(unsigned int). Note that ksmall_array{} is the header for any
possible “small” array build by using the KSA_DECLARE() macro.
