Is there ever a time when I should *not* use the GL* types? If I am writing my own function to check shader compile errors, or do anything that interacts with the OpenGL API but ultimately returns as a result of my application code, should I use the C++ void or GLvoid?

I.E.

GLvoid Shader::check_compile_errors(GLuint ComputeShader, std::string type)
{
    const GLint log_length{ 1024 };
    GLchar info_log[log_length];
    GLint success;

    if (type == "PROGRAM")
    {
        glGetProgramiv(ComputeShader, GL_LINK_STATUS, &amp;success);
        if (!success)
        {
            glGetProgramInfoLog(ComputeShader, log_length, nullptr, info_log);
            std::cout &lt;&lt; "ERROR::PROGRAM_LINKING_ERROR of type: " &lt;&lt; type &lt;&lt; "\n" &lt;&lt; info_log &lt;&lt; "\n ---- " &lt;&lt; std::endl;
        }
    }
 // Here the return is implicitly void, but from C++ not OpenGL!
}


I realize here that GLvoid is typedef'd to void but I am wondering if there is any case where using the GL types could cause issues when it it is not explictly clear that the values are coming from OpenGL.

Another example would be writing an image to a file (from glReadPixels). If I am setting fields in the header which normally takes things in the form unsigned char should I change that to a GLuchar?
Yes, there's a time not to use GL types when interacting with OpenGL: GLvoid. There is absolutely no reason to use this type.

With everything else (assuming you're using a "standard" OpenGL loader), you should use OpenGL's types when talking to OpenGL. That is, the values you pass to OpenGL functions should be in OpenGL's types. This may mean that a function that talks to OpenGL may need an OpenGL data type in its function parameter list. This should be avoided where possible, to prevent you from creating dependencies between OpenGL code and non-OpenGL code.

However, if you don't mind having large portions of your application have dependencies on OpenGL, you may use OpenGL's data types throughout your code.

OpenGL's data types are specified to have a particular bitdepth. As such, they are (conceptually, if not strictly C++-legally) pointer-interconvertible to certain types defined in &lt;stdint.h&gt;/&lt;cstdint&gt;. Indeed, many OpenGL headers will check for the existence of this header and use it wherever it is available to define OpenGL's data types. As such, if you want a fixed bitdepth integer, you have a choice besides using OpenGL's data types.


  I am wondering if there is any case where using the GL types could cause issues when it it is not explictly clear that the values are coming from OpenGL.


OpenGL is C, not magic. A function in C cannot have any control over the return value of the function that calls it. Even a C++ function cannot; at best, it can throw an exception, but this still doesn't have anything to do with its caller's return value.