On Tue, Aug 08, 2023 at 01:42:39PM +0200, Rhialto wrote: > On Tue 08 Aug 2023 at 09:44:41 +1000, matthew green wrote: > > Index: lib/libedit/chartype.c > > =================================================================== > > RCS file: /cvsroot/src/lib/libedit/chartype.c,v > > retrieving revision 1.36 > > diff -p -u -r1.36 chartype.c > > --- lib/libedit/chartype.c 30 Oct 2022 19:11:31 -0000 1.36 > > +++ lib/libedit/chartype.c 7 Aug 2023 23:41:44 -0000 > > @@ -235,17 +235,17 @@ ct_visual_string(const wchar_t *s, ct_bu > > } > > > > /* failed to encode, need more buffer space */ > > - used = dst - conv->wbuff; > > + size_t sused = (uintptr_t)dst - (uintptr_t)conv->wbuff; > > Any particular reason why there is a cast to uintptr_t here? I don't > think there is a guarantee that you can calculate an offset by > subtracting uintptr_ts calculated from pointers. The description in the > C Standard only guarantees that you can convert them back to a pointer > which compares the same to the original, but that's it. I don't find any > other promises about uintptr_t.
Given that we used to make this assumption for offsetof like most systems, this seems to be portable naval gazing to me. Joerg
