PATCH - mark 2: type safe(r) list_entry repacement: con
Quoted 4 lines · Neil Brown
With the "typeof" suggestion from Kevin, I could just change
list_entryand not woory about the fact that lots of people use "list_entry" for things that aren't lists.... but I didn't.
Hello,
is list_entry name really that bad? We have well establishedlist_entry name since at least 2.2.0, and having two same functions with two different names will (IMHO) cause more damage than benefit from "clearer" name is.
Thanks,
Petr Vandrovec
P.S.: I converted whole matroxfb to use list_entry(xxx, struct matrox_fb_info, fbcon) instead of (struct matrox_fb_info*)xxx so that I can move fbcon field from first position in matrox_fb_info - so I'm personally interested in backward source compatibility.
Quoted 11 lines · On Wednesday July 24, [email protected] wrote:
Quoted 4 lines · Neil Brown
With the "typeof" suggestion from Kevin, I could just change
list_entryand not woory about the fact that lots of people use "list_entry" for things that aren't lists.... but I didn't.Hello,
islist_entryname really that bad? We have well establishedlist_entryname since at least 2.2.0, and having two same functions with two different names will (IMHO) cause more damage than benefit from "clearer" name is.
Well... "list_entry" is fine when you are working with a list... but when you aren't it is downright confusing.
The two functions (actually macros) have the same body, but have conceptually different uses. Having extra clues in the code to help readers know what is happening is a *good*thing*.
Quoted 8 lines
Thanks,
Petr Vandrovec
P.S.: I converted whole matroxfb to uselist_entry(xxx, struct matrox_fb_info, fbcon)instead of (struct matrox_fb_info*)xxx so that I can move fbcon field from first position inmatrox_fb_info- so I'm personally interested in backward source compatibility.
In the final patch backward source compatability was not broken, so you should be fine.
NeilBrown