Am 24.06.2018 um 22:12 schrieb Andreas Kemnade andreas@kemnade.info:
On Sun, 24 Jun 2018 20:17:38 +0200 "H. Nikolaus Schaller" hns@goldelico.com wrote:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/power/supply/g...
memcpy(properties + sizeof(*(psy_desc->properties)) * index,
the + of 'properties' and some integer already multiplies the index by sizeof(*properties).
Well, the enum might or might not be 8bit size, so that multiply might be a nop, or it will not be a not at some time.
Lets cite the standard: 6.7.2.2 Enumeration specifiers [...] Constraints The expression that defines the value of an enumeration constant shall be an integer constant expression that has a value representable as an int. [...] Each enumerated type shall be compatible with char, a signed integer type, or an unsigned integer type. The choice of type is implementation-defined, but shall be capable of representing the values of all the members of the enumeration.
Hence it should IMHO be
memcpy(properties + index,
or to better describe that memcpy takes an address
memcpy(&properties[index],
What do you think?
Why not simply
properties[index] = gab_dyn_props[chan];
Because that is far too simple :)
What I assume is that someone developed that before the variable was an enum. Maybe a struct with multiple fields. But even then struct assignments are possible...
But see my overlapping mail - it was originally introduced that way long ago in 3.7-rc1.
Now I am curious what your statistical test shows. It is of course a much better validation than mine (with 0/5 failures vs. 1/3 failures).
BR, Nikolaus