Hello,
-
On *32-bit systems*, UINTPTR_MAX is 0xFFFFFFFF
-
On *64-bit systems*, UINTPTR_MAX is 0xFFFFFFFFFFFFFFFF
That is what we want, right?
Also passing anything larger than 0xFFFFFFFF (like ~0ULL) on a 32-bit build
causes *overflow and truncation*, and triggers warnings.
On Mon, Jun 23, 2025 at 9:08 PM Damien Zammit <dam...@zamaudio.com> wrote:
> But on 64 bit, isn't the value supposed to be sign extended to the full
> width not uint32 max?
>
> Damien
>
> Sent from Proton Mail Android
>
>
> -------- Original Message --------
> On 24/6/25 9:59 am, Milos Nikic <nikic.mi...@gmail.com> wrote:
>
> > From: Milos Nikic <nikic.mi...@google.com>
> >
> > The call to vm_object_print_part was passing 0ULL and ~0ULL
> > for offset and size, respectively. These values are 64-bit
> > (unsigned long long), which causes compiler warnings when
> > building for 32-bit platforms where vm_offset_t and vm_size_t
> > are typedefs of uintptr_t (i.e., unsigned int).
> >
> > This patch replaces those constants with 0 and UINTPTR_MAX,
> > which match the expected types and avoid implicit conversion
> > or overflow warnings.
> >
> > No functional change.
> > ---
> > vm/vm_object.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/vm/vm_object.c b/vm/vm_object.c
> > index 2dba76b1..409a64e3 100644
> > --- a/vm/vm_object.c
> > +++ b/vm/vm_object.c
> > @@ -36,6 +36,7 @@
> > #include <kern/printf.h>
> > #include <string.h>
> >
> > +#include <stdint.h>
> > #include <mach/memory_object.h>
> > #include <vm/memory_object_default.user.h>
> > #include <vm/memory_object_user.user.h>
> > @@ -3050,7 +3051,7 @@ void vm_object_print_part(
> > void vm_object_print(
> > vm_object_t object)
> > {
> > - vm_object_print_part(object, 0ULL, ~0ULL);
> > + vm_object_print_part(object, 0, UINTPTR_MAX);
> > }
> >
> > #endif /* MACH_KDB */
> > --
> > 2.50.0
> >
> >
> >
>
