servo / sparkle Goto Github PK

Methods Gl::buffer_data and Gl::sub_buffer_data pass slices of arbitrary T values to the GL system, but those Ts may have padding, which is uninitialised, which means we are passing uninitialised data to the GL system that may be read back by Rust later. The T type parameter should be constrained by some sort of unsafe trait to prevent that.

Cargo.toml says it's MIT / Apache-2.0 but lib.rs says it's MPL2.0.

One thing we hit in webxr was that gleam doesn't provide a standard API for a GlFactory, that would implement Send and Clone, and would build new Rc<dyn Gl> objects. Servo rolls its own, but there's no way to have those be used by webxr without having webxr depend on servo. It might be nice to put that API in sparkle.

Those methods take a buffer, pass it to a GL API as a pointer, and let GL decide how many bytes it should read from it through a combination of other inputs (for example, width and height), these methods should be unsafe:

• Gl::tex_image_2d
• Gl::tex_sub_image_2d

Furthermore, the GL functions for compressed textures also specify that undefined results can occur "if data is not encoded in a manner consistent with the extension specification defining the internal compression format", so the two methods using them should probably marked as unsafe too:

• Gl::compressed_tex_image_2d
• Gl::compressed_tex_sub_image_2d

Method Gl::get_tex_parameter_iv when passed GL_TEXTURE_BORDER_COLOR will try to write four integer values in a &mut GLint which is obviously not large enough.

The same thing can happen with Gl::get_tex_parameter_fv.

For now, it can't happen with Gl::get_framebuffer_attachment_parameter_iv and Gl::get_renderbuffer_parameter_iv because all framebuffer attachment and renderbuffer parameters are single-valued, but nothing guarantees us that this will be true of all GL extensions in the future, so I would make it unsafe too.

Cc @kvark with whom I had debated about that in the past when it was a problem in gleam.