https://bugs.freedesktop.org/show_bug.cgi?id=33558

Ian Romanick <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|[email protected]. |[email protected]
                   |org                         |

--- Comment #3 from Ian Romanick <[email protected]> 2011-02-07 14:01:57 PST 
---
This part of the patch confuses me:

@@ -526,21 +529,26 @@ getFBConfigs(__GLXscreenConfigs *psc, __GLXdisplayPrivate
*priv, int screen)
    LockDisplay(dpy);

    psc->configs = NULL;
-   if (atof(priv->serverGLXversion) >= 1.3) {
-      GetReq(GLXGetFBConfigs, fb_req);
-      fb_req->reqType = priv->majorOpcode;

[snip]

+   number = (GLfloat) _GLstrtof(priv->serverGLXversion, &end);
+   if (end && end > priv->serverGLXversion) {
+      if (atof(priv->serverGLXversion) >= 1.3) {
+     GetReq(GLXGetFBConfigs, fb_req);
+     fb_req->reqType = priv->majorOpcode;

Why is it necessary to call _GLstrtof and atof?  The documentation for strtof,
on which _GLstrtof is based, says:

       If no conversion is performed, zero is returned and the value  of  nptr
       is stored in the location referenced by endptr.

This is the same assumption that the old atof code makes.  We either get the
GLX version or, in the case of a malformed string, 0.0.  In any case where the
value is less than 1.3, we use the GLX 1.2 protocol.

Unless I've missed something (possible), it should be safe to replace the
existing call to atof with a call to the new _GLstrtof.

Also, I think it's better to call the new function __glXStrtof.  This matches
the naming convention of other internal GLX functions.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to