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

@kas1e


It's on the autodoc for such "strange" values.

https://wiki.amigaos.net/amiga/autodocs/intuition.doc.txt



NAME
SetWindowTitles -- Set the window's titles for both window and screen.

SYNOPSIS
void SetWindowTitles(struct window *win, CONST_STRPTR window_title, CONST_STRPTR screen_title);

FUNCTION
Allows you to set the text which appears in the Window and/or Screen title bars.
...
You can specify a value of -1 (i.e. (STRPTR) ~0) for either of the title pointers. This designates that you want Intuition to leave the current setting of that particular title alone, and modify only the other one. Of course, you could set both to -1.

Furthermore, you can set a value of 0 (zero) for either of the title pointers. Doing so specifies that you want no title to appear (the title bar will be blank).
...

@jabirulo
Quote:
Yeah, read it all yesterday already. Is it only SetWindowTitles allowing -1 or there are more ? I see NULL is acceptable offten, but -1 ?

@kas1e

Quote:

I see jabirulo got there first....

Quote:

It's not uncommon for a few special values for strings, we mainly get away with this due to the signed 32 bit memory space, so 0xFFFFFFFF will "never" be a valid pointer to a string.

But check with the autodocs of each function / tag, some places bad things will happen