The mmap calls in the WT back end return two pointers (one the address of the mapped region, the other an extra cookie used by Windows), but do this with an argument of type void * rather than of type void **.

This should really be corrected if possible.

This use of void * instead of void ** to accept a pointer to an arbitrary pointer occurs because because if x is a foo * rather than a void *, passing &x to an argument of type void ** is rejected by the compiler. Declaring the argument as void * prevents this check, and works on all real machines (as opposed to those run only by comp.lang.c contributors). Consequently it avoids having to declare an extra scratch variable of type void * at the call site and assign it into the real pointer afterwards.

However, it's unsafe (in that you can accidentally pass x instead of &x and it won't be caught), and also hiding formally undefined behavior (at least with strict-aliasing enabled) and that might eventually lead to problems. Furthermore, the call sites we have are already passing the address of a void *, so there's no particular need for this leeway.

The change technically changes the signatures of the affected functions, but I know of no real machine where this change will actually affect the function call ABI, so as best I know it won't break binary compatibility.

However: the change also affects the WT_FILE_HANDLE map call, which is published in the extension API. This should still not break the build of any formally correct usage calling it, but if we think someone out there is taking advantage of the leeway, or providing their own file handles with map support (the latter seems pretty unlikely, granted) maybe we shouldn't do this.