My approach on this is that if you grab an extension function pointer for an extension that the driver does not claim to support, it “probably” isn’t safe (in theory) to call the function.
There is only one official way of determining whether an extension is supported, and that is to look at the extension string.
In theory, if it’s not in the extension string, wglGetProcAddress should return NULL. I think we implement this correctly in our driver, but there may be a few cases where it isn’t entirely correct and you may be able to pull out a function pointer for a function that isn’t supported. If so, that’s a bug. An analogous situation is that if you give us an enumerant for an extension that we support on one configuration but not on another, we should be rejecting it with an INVALID_ENUM error on the configuration that does not support it. There are probably cases where we don’t do that properly, but again, if you find one, it’s a bug and I will fix it.
Relying on wglGetProcAddress to determine extension availability is a quick and certain path to a compatibility nightmare.
Likewise, relying on whether an enumerant appears to generate an INVALID_ENUM error is a bad way to determine extension availability.
Now, your question only concerned function pointers, but enumerants come up pretty quickly when you start talking about extensions. For example, with texture compression, one way you can use the extension is to pass, e.g., COMPRESSED_RGB_ARB to TexImage2D and have the driver perform compression. In this case, it seems you’re in trouble. If you trust the extension string, you’d never know that you could pass COMPRESSED_RGB_ARB as the internal format. But if you distrust it and check for extension availability by trying to pass it and seeing if you get an error, well, that’s no good either.
As for how to solve your particular problem, I don’t know…