Ah yes, good.
Damien
Sent from Proton Mail Android
-------- Original Message --------
On 24/6/25 2:30 pm, Milos Nikic wrote:
> 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
>>>
>>>
>>>
