I would actually opt for updating any expressions from „curPos“ to „(curPosInBits/8)"
Chris Von: Sebastian Rühl <[email protected]> Datum: Mittwoch, 17. September 2025 um 15:59 An: [email protected] <[email protected]> Betreff: Re: AW: [DISCUSS] Make "curPos" a bit-position? ack. Do you think we should name the other method then curPosInBytes too? - Sebastian On 2025/09/17 13:54:42 Christofer Dutz wrote: > I see it the same way … but I think we can make things simpler, if we name > things differently. > So „curPosInBits“ would be a better way of naming it, as it explicitly states > what we’re counting. > In most of IT it’s always bytes. > > Chris > > Von: Sebastian Rühl <[email protected]> > Datum: Mittwoch, 17. September 2025 um 15:50 > An: [email protected] <[email protected]> > Betreff: Re: [DISCUSS] Make "curPos" a bit-position? > > I would even go that far and always use bit positions and only use byte > positions for box rendering and as utility method. Also making the type more > explicit in the name is a good idea I think. > > - Sebastian > > On 2025/09/16 19:40:32 Christofer Dutz wrote: > > Hi all, > > > > Just came back from Minneapolis this morning and was continuing my work on > > cleaning up PLC4X. Here I noticed one thing, that could cause problems. > > > > It seems that „curPos“ in mspec refers to the byte-position in the > > byte-buffer. This has never caused issues before, but I know there are > > protocols out there, that have non byte aligned complex objects. I think in > > firmata there were types that were only 4 bits long. > > > > By sticking to the bytePosition, we will have issues modeling such > > protocols fully. > > > > If however, we updated our mspecs to expect curPos to be a bit-position, we > > would avoid this type of problem. > > > > What do you think? Should we update this? I also think that it might be > > beneficial to be a bit more explicit. We could add a „curBitPos“ and rename > > the existing „curBytePos“ for compatability reasons. > > > > Chris > > >
