fit: Fixed subfield referencing fields below self in message #877
Conversation
| switch fDef.Type { | ||
| case "enum", "uint8", "uint8z", "byte": | ||
| val = peekUintBitsEndian(d, 8) | ||
| valMap[fDef.Name] = valueType{value: val, typ: fDef.Format} |
There was a problem hiding this comment.
Could these use d.U(<nBits>)? that one should respect current endian
There was a problem hiding this comment.
But yes maybe something like PeekUintBitsEndian could be useful... wonder even if peekUintBits should actually respect current endian? or maybe those should be d.Peek<type> like d.PeekU(24)? could probably even generate code for those.
There was a problem hiding this comment.
Dammit =) I was looking at the d.U (and all the d.Ux, d.UxLE etc) functions in the lounge at the hotel in Brussels, and now they completely slipped my mind. Yes, d.U would work and look better. I'll fix it.
There was a problem hiding this comment.
😄 maybe the decode API is not the most "discoverable", have some vague idea how maybe it could be made nicer, maybe use generic and methods chaining more? but the current keep it "dumb" and generate-design it quite nice also :)
There was a problem hiding this comment.
And just as you merged, I realized that although there are no reference fields that are also array types, there might be some that would throw of the value gathering, so I need to fix that too. =) another PR incoming soon
72df677 to
f7b067b
Compare
|
👍 Will merge once CI is happy I wonder if one could have a type to bit size table somehow and simplify it even more? When reviewing the code i was thinking if there are some things that are now looked up by string could use int constant somehow? |
Generally fDef.size should dictate how many bytes to read for each field, since there are many fields (those labeled UNKNOWN_X) that are not in the official Profile spec. |
Some subfields are referencing fields that come after themselves in the message. This is allowed by spec, but means that data messages have to be pre-read to include all potential reference fields. I did this with d.PeekUintBits, but had to wrap in since that method ignores d.Endian.
Maybe my peekUintBitsEndian should be moved to the decode package?