On Wed, Oct 19, 2022 at 4:35 PM Stanislav Fomichev <sdf@xxxxxxxxxx> wrote: > > On Wed, Oct 19, 2022 at 2:06 PM Dave Thaler <dthaler@xxxxxxxxxxxxx> wrote: > > > > sdf@xxxxxxxxxx wrote: > > > > ``BPF_ADD | BPF_X | BPF_ALU`` means:: > > > > > > > - dst_reg = (u32) dst_reg + (u32) src_reg; > > > > + dst = (u32) (dst + src) > > > > > > IIUC, by going from (u32) + (u32) to (u32)(), we want to signal that the value > > > will just wrap around? > > > > Right. In particular the old line could be confusing if one misinterpreted it as > > saying that the addition could overflow into a higher bit. The new line is intended > > to be unambiguous that the upper 32 bits are 0. > > > > > But isn't it more confusing now because it's unclear > > > what the sign of the dst/src is (s32 vs u32)? > > > > As stated the upper 32 bits have to be 0, just as any other u32 assignment. > > Do we mention somewhere above/below that the operands are unsigned? > IOW, what prevents me from reading this new format as follows? > > dst = (u32) ((s32)dst + (s32)src) The doc mentions it, but I completely agree with you. The original line was better. Dave, please undo this part.
