When tasked with diagnosing why a pointer passed through a pipeline emerged offset from its original value, I discovered an interesting culprit: the misuse of a wrapper function around SubmitWork. While the wrapper aimed to simplify usage by allowing both raw pointers and references to standard layout types, it inadvertently caused ambiguous overload resolution, leading to incorrect behavior. This analysis explores how the issue arose, the debugging process, and improvements to ensure robust and predictable pointer handling in similar scenarios.

In C++, failure to meet the requirements does not always mean that you fail if you don’t meet the requirements

by Raymond Chen

From the article:

I was asked to help debug a problem where a pointer passed to a function was received slightly offset from the original value. The pointer is passed as an opaque parameter and is supposed to be spit out the other end of a pipeline. But somehow, the value that came out the other end was slightly different.

For expository purposes, let’s say that the underlying function we’re trying to call is this one.

void SubmitWork(HWORKER worker, int commandCode, void* param);

You call Submit­Work with a worker, a command code, and a raw pointer to some data that depends on the command code.

The developer sent me some debugging output that showed that the function that handled the command code received a different pointer from what was passed. One possibility is that there was a bug in the library that resulted in it unintentionally modifying the final pointer parameter, but this seemed unlikely, since the value should be opaque to the library. I was able to get on a video call with the developer to watch them step through the code, and that’s where I noticed something interesting.