On 19/01/2023 10:50 am, Jan Beulich wrote: > On 18.01.2023 19:21, Anthony PERARD wrote: >> On Tue, Jan 17, 2023 at 05:21:32PM +0000, Andrew Cooper wrote: >>> On 16/01/2023 6:10 pm, Anthony PERARD wrote: >>>> +def get_typedefs(tokens): >>>> + level = 1 >>>> + state = 0 >>>> + typedefs = [] >>> I'm pretty sure typedefs actually wants to be a dict rather than a list >>> (will have better "id in typedefs" performance lower down), but that >>> wants matching with code changes elsewhere, and probably wants doing >>> separately. >> I'm not sure that going to make a difference to have "id in ()" instead >> of "id in []". I just found out that `typedefs` is always empty... >> >> I don't know what get_typedefs() is supposed to do, or at least if it >> works as expected, because it always returns "" or an empty list. (even >> the shell version) >> >> So, it would actually be a bit faster to not call get_typedefs(), but I >> don't know if that's safe. > There's exactly one instance that this would take care of: > > typedef XEN_GUEST_HANDLE(char) tmem_cli_va_t; > > But tmem.h isn't being processed anymore, and hence right now the list > would always be empty. Are we going to be able to guarantee that going > forward?
IMO that's a code pattern we wouldn't want to repeat moving forward. There's already too much magic in a guest handle, without hiding it behind a typedef too. ~Andrew
