The null pointer is guaranteed by C standards to never contain any valid object or function, but Quake's virtual machines seem to allow both writing to and reading from NULL without any obvious side-effects.
I suggest that if the QVM tries to dereference a null pointer the server binary should immediately terminate it with an appropriate error message.
Can you quote the paragraph of the C standard that forbids the use of NULL? :)
It's not forbidden. It just doesn't normally work as the memory page add address zero is not mapped. If you manually map NULL (via mmap and MAP_FIXED, see mmap manpage) you can access that area just fine.
Regardless of the standards, any architecture I've ever come across will complain wildly if you deference NULL. It /should/ crash if such an operation is attempted since otherwise a bug is hidden. I don't think an irrelevant standard is justification for WONTFIX.
Fixing this would require special memory allocation for qvms in which the first page of memory is reserved. This can cause issues because page size varies between architectures and there is no portable API to do per-page memory allocation which guarantee that an unused page will cause a segfault.
On the other hand I agree that qvms _should_ crash when dereferencing NULL since many people don't test their mods with dll/so.
Ludwig: I'm looking at an ISO C99 draft retrieved from http://www.open-std.org/jtc1/sc22/wg14/www/standards.html#9899
6.3.2.3 Pointers
[...]
3 An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant. If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.
(In reply to comment #0)
> Quake's virtual machines seem to allow both writing to and
> reading from NULL without any obvious side-effects.
There is a side effect to reading and writing to NULL. In qvms NULL will point to the begining of the data segment, which is the vmCvar_t memory at the begining of {g|cg|ui}_main.c. A simple way to fix this would be to allocate a 0 filled buffer right at the begining of the data section.
In order to keep compatibility with existing qvms I have not used a new magic number in the qvm header. Instead, I placed set the first byte of the data section to 1, as it is always 0 in current qvms.
Created attachment 1813 [details] Patch that catches NULL derefs from qvmsCreated attachment 1814 [details] Fixed patchCreated attachment 1839 [details] Updated patch Maybe also allow this feature to be toggled by a cvar?