On Tue 08 Aug 2023 at 14:10:41 +0200, Joerg Sonnenberger wrote: > 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.
It is one thing to hide such an assumption away in a macro (and with all compilers currently in use, offsetof() is mapped to __builtin_offsetof() (see <stddef.h>), which quite likely exists because of the unstandardness of the other version), but quite another to open-code it again and again in general code. <advocacy type="devil">Think of the PDP-10 port!</> I was expecting some sort of answer related to unsigned vs signed sizes and differences, or something like that, for which there is likely a cleaner solution. > Joerg -Olaf. -- ___ Olaf 'Rhialto' Seibert <rhialto/at/falu.nl> \X/ There is no AI. There is just someone else's work. --I. Rose
signature.asc
Description: PGP signature
