Modernize NULL with nullptr in newview #5107
Conversation
| LPCWSTR unique_mutex_name = L"SecondLifeAppMutex"; | ||
| HANDLE hMutex; | ||
| hMutex = CreateMutex(NULL, TRUE, unique_mutex_name); | ||
| hMutex = CreateMutex(nullptr, TRUE, unique_mutex_name); |
There was a problem hiding this comment.
Bulk searched & replaced? Windows API calls should IMHO keep using NULL.
There was a problem hiding this comment.
I'm curious about the reasoning for this. Not saying you are wrong but would like to learn the possible pitfalls with this.
There was a problem hiding this comment.
NULL equals to 0 and I don't think we should mess with the expected values of the Windows API. This and the other PR just look like a bulk search and replace change without taking OS-specific API implementations into account.
It is kinda weird this and the other PR use 3P compatibility as a reasoning for this change, but then completely disregards OS-specific API implementations. This line is just a placeholder for all changes using OS-specific API call and there a for sure a bunch more of these cases. In this particular case, you can even notice that TRUE hasn't changed to true for exactky that reason.
I don't dislike or dismiss the idea of this PR in general, but it seems like a bulk search and replace PR without taking individual cases into account.
There was a problem hiding this comment.
Can't argue with this. It probably is a bulk replace. What I wondered is, does nullptr not resolve to a the same actual 0x0000000000000000 value being passed on the stack? Maybe in certain compiler backends or whatever?
I can understand that the NULL was always a bit of a hack that was there because of the lack of a compiler native definition, but I would expect both to resolve ultimately to the same code unless there is some library specific optimization that a compiler "might" employ. For the WinAPI I would expect a compiler to stay far from trying to do any such silly things if it does not want to break anything in spectacular ways. But I'm learning here and just as with the STL being still quite an unfamiliar thing until now, I also am far from being even a C++ specialist.
Maybe there exist compilers that would bark on nullptr being passed to a standard C pointer of anything? Would seem weird but I'm not claiming it could not exist.
There was a problem hiding this comment.
well I thought this was going to be an issue, but looks like MS has come around on this: https://devblogs.microsoft.com/oldnewthing/20180307-00/?p=98175
There was a problem hiding this comment.
well I thought this was going to be an issue, but looks like MS has come around on this: https://devblogs.microsoft.com/oldnewthing/20180307-00/?p=98175
Based on this esoteric answer, why not also debate about replacing TRUE/FALSE with true/false when dealing with Windows API calls?
Also: Can he guarantee it works? Did he go through all the Windows API code and vouch for his "bonus bonus chatter" case isn't going to fall on his feet somewhere in the Windows API?
"Bonus chatter": I only picked the Windows case as an example. I assume macOS and Linux specific code also got the bulk replacement treatment. Can we guarantee nothing is going to break there as well?
There was a problem hiding this comment.
I think this is mainly a compiler issue. Technically what happens is that both values ultimately cause a 0x0000000000000000 value being passed on the stack. The function itself won't even be able to tell at runtime which of the two "values" was used to create the null pointer. So fears that Windows APIs might fail if passed a nullptr for pointer variables, which handles are also, seem rather far fetched (of course only if NULL is a documented valid value to be passed to that parameter).
There could be issues with replacing NULL value assignments to parameters that really are integral types instead of pointers. But that would cause a compilation error, since C++ does not allow nullptr to be assigned to integral types. And it would have been syntactically bogus code already. While you can do int b = NULL, that is not something that is normally accepted coding practice at this time.
So I would think, if it compiles, it should be fine.
The true/false issue is slightly more complex. TRUE or FALSE is defined as 1 or 0 respectively without an explicit type normally. true or false is a compiler type definition that results in an explicit boolean value of 1 or 0, which for most compilers is an 8 bit value. So there might be size assignment issues depending how strict a compiler is. true or false assigned to a Windows BOOL are most likely going to work ok as they will be simply extended to the Windows 32 bit value, but it is potentially more tricky.
There was a problem hiding this comment.
So - although the standard does not guarantee what nullptr will end up being, I think it's probably safe to assume the Windows APIs will likely accept and function with nullptr fine.
The article that @brad-linden discovered more or less alludes to this, and I think it's unreasonable to check each and every single API to ensure that this is the case. On macOS nullptr seems to be fine - at least from my experience thus far. Linux - that's the better question, but ultimately we should just run it and see what happens.
Positing "this may happen" vs. "this will happen" with zero evidence is rarely productive in these efforts, especially when for the most part it seems reasonably safe (some cursory research on how glibc will handle this seems to indicate it should be safe under GCC at least, though I'm finding it difficult to find specific info - many seem to just accept it as fine in practice FWIW).
The alternative is to switch back to NULL where we think we need it.
5 participants
Description
Modernize NULL with nullptr in newview for increased type safety and compatibility with modern c++ library expectations that compare to nullptr_t but have no compatibility for NULL.
Related Issues
Issue Link: #5078
Checklist
Please ensure the following before requesting review:
Additional Notes