glDepthRange (4.2+) vs. glDepthRangedNV

In the 4.2 spec the definition of glDepthRange was changed to

void DepthRange( double n, double f );
from previous
void DepthRange( clampd n, clampd f );
with the wording changed to “If a fixed-point representation is used, the parameters n and f are clamped to the range [0; 1] when computing zw.

So I expected it to behave like glDepthRangedNV that explicitly states that the values of n and f are not clamped. However, with glDepthRange with 4.2 core context and 306.97 NV drivers I’m reading back clamped values. Am I doing something wrong or have I read the spec incorrectly, assuming that with the floating point representation (of depth buffer) n and f would not be clamped?

It seems to be a clear driver bug.

Assuming that your depth buffer actually is GL_DEPTH_COMPONENT32F, of course.

No, this is a spec bug. Despite removal of GLclamp, all depth values are always clamped to [0,1].

No, this is a spec bug. Despite removal of GLclamp, all depth values are always clamped to [0,1].

No, that is a driver bug. The spec says what ought to happen; drivers are supposed to comply with that. If they don’t, it’s the driver’s fault.

This was a deliberate change in a revision of the spec document. It’s even stated in the changelog for 4.2 exactly why it was changed. If a driver isn’t doing what it says, that’s the driver’s fault. Depth values are not always clamped.

The spec is wrong. Get Khronos membership and go read Bugzilla #9517.

Depth is always clamped in core OpenGL (but not in Nvidia extensions.)

If depth is always clamped, what good is GL_DEPTH_COMPONENT32F? Is there a bug to remove that too? And who filed that bug, since the ARB deliberately made this change to allow unclamped depth ranges?