generate_packets.py: erroneous output when some (but not all) variants of a packet have no fields
alienvalkyrie alienvalkyrie The simple-seeming solution (doing stuff based on Packet.no_packet rather than Variant.fields) unfortunately leads to code that still doesn't compile (in debug mode at least) – the lack of a __dummy field means nothing is written to the packet struct in the receive handler, which gives "potentially uninitialized" warnings, and the send handler ends up with unused variables.
Since this turned out to be more complex than anticipated, while not a pressing concern at all, I'll put this on the back burner. I'm considering just treating this edge case as unsupported; it seems quite unlikely that an empty variant of a packet that usually carries information would be intended anyhow.
alienvalkyrie alienvalkyrie I've gone with the option of explicitly unsupporting this edge case, since again – if it ever actually happens in practice, that's almost certainly an accident.
alienvalkyrie 
Packets with no fields are handled differently from packets with fields. Some code in generate_packets.py only looks at a variant's fields to determine whether this is the case, so if a packet has fields, but one of its variants does not, that causes problems. This happens when all fields of a packet are add-cap or remove-cap, and no capability is used for both.
As far as I can tell, if this ever occurs in practice, the resulting code will not compile, so it won't result in sneaky issues that remain undetected and actually get committed.