NULL, 0xFFFFFFFF and Exec: Real vs QEMU

@All
Can plz somehow clarify a bit this moment i found:

I patch the SetWindowTitles() via usual SetMethod, to just print what kind of arguments it takes when called differently in different scenarios. And find out interesting detail: when code send a NULL for windwotitle or to screentitle (both of which CONST_STRPTR so mean const char *) , patched function see those NULLs as 0xFFFFFFFF ! While it's clear that NULL are 0 , and 0xFFFFFFFF is different and an address, i surely see in patched function that it always 0xFFFFFFFF (which probably Exec sends ?) when any kind of code call SetWindowTitles with any NULL for any argument.

Why ?

And second question, about more general situation : on real hardware, when i tried to print what i receive (in this case 0xFFFFFFFF) i of course crashes, because 0xFFFFFFFF address surely invalid. But, on QEMU i didn't crash, it just print nothing (empty), but not crashes.

Why ?

Thanks for answers !

It is legal and documented for programs to pass 0xffffffff as windowtitle or screentitle and it means leave it unchanged. In case program wants to change only window title or only screen title.

I'm not sure what you mean with "code sends NULL" but you see 0xffffffff. Whatever params program passes to function you should see in patched function exactly the same. Exec is not involved at all.

@kas1e
Sorry, I don't know this functions. But for example const EOF is represented as -1 and is integer type.
Can be there some mismatch EOF vs NULL?

@Georg
Quote:

I just weren't aware about, and when i see that both windowtitle and screentitle are CONST_STRPTR , i were sure i can printf it just by %s , and so got crashes all the time. I then check on just NULL, it was better , but still not, then i realise it had 0xFFFFFFF sometime, so then i check on this one too before doing print with %s. I just find it strange at first look that things which marked in function as CONST_STRPTR allowed some values which is not string. Is there any other functions in system libs which being %s allowed something else except null and 0xffffffff ?

There was a patch recently to fix address wrap around (https://patchew.org/QEMU/2025050420571 ... ard.henderson@linaro.org/) so probably before that QEMU did not check this. Are you using latest QEMU from git where this patch should already be merged?

@balaton
Quote:
I just on 10.0.0 one (the one from https://qemu.weilnetz.de/w64/2025/, called qemu-w64-setup-20250422.exe), so nope, this one not in for my build. But then if it know and fixed that always cool to be on pair with real hw