On Thu, 18 Feb 2021 05:49:41 +0200 Tzvetomir Stoyanov <tz.stoyanov@xxxxxxxxx> wrote: > This works for the current structure of trace.dat file, we can have > these assumptions > and use state instead of a bitmask. But in the future, if we decide to > add optional > sections in the file, or more complex branches - assumptions could not > be valid and > state should be changed to something more flexible. And why I think it's good to have both a state enumeration (for things that must exist in a particular order) and flags for things that are optional and you don't care about order. > As this is not part of any external API, I'm OK to change bitmask to > state. This easily > can be redesigned in the future, if needed. Yes, this can most definitely change in the future, and I like that you are thinking about the future and ways to be flexible. But we also don't want to make things too complex. Having a state enumeration (counter) and flags together handles all cases, and I would recommend doing so as a counter. If there's something that's optional, we can use the flags. Care to send a v2? Thanks! -- Steve
|