GetStringi failure won't get handled

[okias]

after compilation of latest minetest + irrlicht I see regression:

minetest/src/main.cpp:116: int main(int, char**): A fatal error occurred: "basic_string: construction from null is not valid

8c521939b9a93834df3b1536e1850101f31cb89c regresses on Mesa.

extensions.emplace((char *)GetStringi(EXTENSIONS, k)); return NULL, as it can (looking at the spec [1]). When I encapsulate that with

diff --git a/source/Irrlicht/mt_opengl_loader.cpp b/source/Irrlicht/mt_opengl_loader.cpp
index 26de3d3..581188a 100755
--- a/source/Irrlicht/mt_opengl_loader.cpp
+++ b/source/Irrlicht/mt_opengl_loader.cpp
@@ -761,7 +761,10 @@ void OpenGLProcedures::LoadAllProcedures(irr::video::IContextManager *cmgr)
        GetIntegerv(NUM_EXTENSIONS, &ext_count);
        extensions.reserve(ext_count);
        for (int k = 0; k < ext_count; k++)
-               extensions.emplace((char *)GetStringi(EXTENSIONS, k));
+               auto ext = GetStringi(EXTENSIONS, k);
+               if (!ext)
+                 continue;
+               extensions.emplace((char *)ext);
        if (ext_count)
                return;

it works, but the extensions aren't loaded (since every call returns NULL).

[1] https://registry.khronos.org/OpenGL-Refpages/es3.0/html/glGetString.xhtml

@numberZero

P.S. also I see lot of GL_Invalid_operations, thou running latest Intel driver.

[numberZero]

Missing braces aside, the patch looks workable. Although if (auto ext = GetStringi(EXTENSIONS, k)) might be cleaner.

but the extensions aren't loaded

They should be loaded a few lines later via the older GetString call.

Anyway, it’s weird the driver reports non-zero NUM_EXTENSIONS but refuses to give away actual names.

P.S. The spec you wanted is likely https://registry.khronos.org/OpenGL-Refpages/gl4/html/glGetString.xhtml. Unless you actually use OpenGL ES on desktop (Mesa does support that).

[okias]

Exactly as you write, I think there is different issue with querying.

I compiled some demo with glew and glfw3 and the query works just fine. With irrlicht it doesn't.

[okias]

The issue I had got fixed by some recent commit; I'll send MR for making this more robust anyway :)

[okias]

Thanks! Now the code look more C++ :yum: