no the question was, does this then turn out to be 4 or 5? (also something that jumped to my mind if we could overflow as instead of max int we only support max int / 8 as max :D)
- Sebastian On 2025/09/17 15:28:51 Christofer Dutz wrote: > Well … currently there is no case where this would not turn out to be an > integer as all places are 8-bit aligned. > Theoretically even an error would be good, because what the hell would you do > with getting „4.5433“? > > Chris > > Von: Sebastian Rühl <[email protected]> > Datum: Mittwoch, 17. September 2025 um 16:19 > An: [email protected] <[email protected]> > Betreff: Re: AW: AW: [DISCUSS] Make "curPos" a bit-position? > > sounds good to me. Just quick sanity check: does this always ceil? > > - Sebastian > > On 2025/09/17 14:09:07 Christofer Dutz wrote: > > 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 > > > > > > > > > >
