Source-Changes-D archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/share/mk
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
Home |
Main Index |
Thread Index |
Old Index