The conversion of window icon image data involves unsigned char color
values being promoted to int and then shifted to the left by 24. For
32-bit ints this is just far enough to trigger undefined behavior.
It worked by accident because of how current compilers translate this
piece of code.
This was caught by @slimsag while working on [Zig bindings for GLFW][1],
and diagnosed together with @Andoryuuta, as described [in an
article][2]. Zig has UBSan enabled by default, which caught this
undefined behavior.
[1]: https://github.com/hexops/mach-glfw
[2]: https://devlog.hexops.com/2021/perfecting-glfw-for-zig-and-finding-undefined-behavior#finding-lurking-undefined-behavior-in-6-year-old-glfw-code
Thanks to Maato, martinhath, dcousens, drfuchs and Validark for helping
to refine the solution.
This commit message was rewritten by @elmindreda to hopefully reflect
the conclusions of the pull request thread.
Related to hexops/mach#20
Closes#1986
(cherry picked from commit 9cd4d2fa20)
The monitor handle could have become invalid just before the call to
GetDpiForMonitor. It was possible for both window and monitor content
scale queries.
This ensures both that an appropriate error is emitted and that the
retrieved values are zero on error.
Fixes#1615
The conversion of window icon image data involves unsigned char color
values being promoted to int and then shifted to the left by 24. For
32-bit ints this is just far enough to trigger undefined behavior.
It worked by accident because of how current compilers translate this
piece of code.
This was caught by @slimsag while working on [Zig bindings for GLFW][1],
and diagnosed together with @Andoryuuta, as described [in an
article][2]. Zig has UBSan enabled by default, which caught this
undefined behavior.
[1]: https://github.com/hexops/mach-glfw
[2]: https://devlog.hexops.com/2021/perfecting-glfw-for-zig-and-finding-undefined-behavior#finding-lurking-undefined-behavior-in-6-year-old-glfw-code
Thanks to Maato, martinhath, dcousens, drfuchs and Validark for helping
to refine the solution.
This commit message was rewritten by @elmindreda to hopefully reflect
the conclusions of the pull request thread.
Related to hexops/mach#20
Closes#1986
This docstring previously indicated that GLFW_CONTEXT_REVISION was
a window hint and attribute, but in fact it is only a window attribute
(there is no code which uses this constant in any other context.)
We noticed this in https://github.com/hexops/mach/pull/71/files#r749741814Closes#1992
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
(cherry picked from commit 37fc28bff6)
Add GLFW_FORMAT_UNAVAILABLE to the list of possible errors in the
reference documentation for glfwGetClipboardString.
Slightly edited by @elmindreda.
Closes#1998
(cherry picked from commit bb193325cc)
This docstring previously indicated that GLFW_CONTEXT_REVISION was
a window hint and attribute, but in fact it is only a window attribute
(there is no code which uses this constant in any other context.)
We noticed this in https://github.com/hexops/mach/pull/71/files#r749741814Closes#1992
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
Add GLFW_FORMAT_UNAVAILABLE to the list of possible errors in the
reference documentation for glfwGetClipboardString.
Slightly edited by @elmindreda.
Closes#1998
Joysticks already connected when GLFW was initalized did not get gamepad
mappings applied to them.
Regression introduced by 74a8ba26c3.
This change was backported without taking into account that 3.3.x does
not have on-demand joystick init.
Fixes#1996
Looking into the definition of kIOMainPortDefault, the following
description can be found:
When specifying a main port to IOKit functions, the NULL argument
indicates "use the default". This is a synonym for NULL, if you'd
rather use a named constant.
Thus, we do not have to utilize an external symbol for the identifier
of the default main IOKit port, but MACH_PORT_NULL suffice. This
simplifies compatibility between macOS versions as the symbol was
renamed with macOS 12.0.
Fixes#1985Closes#1994
(cherry picked from commit 544790666b)
Looking into the definition of kIOMainPortDefault, the following
description can be found:
When specifying a main port to IOKit functions, the NULL argument
indicates "use the default". This is a synonym for NULL, if you'd
rather use a named constant.
Thus, we do not have to utilize an external symbol for the identifier
of the default main IOKit port, but MACH_PORT_NULL suffice. This
simplifies compatibility between macOS versions as the symbol was
renamed with macOS 12.0.
Fixes#1985Closes#1994
This adds a workaround for kIOMasterPortDefault having been deprecated
in favor of kIOMainPortDefault in macOS 12.0.
Closes#1980
(cherry picked from commit f75c251dec)
The GLFW_INCLUDE_GLCOREARB branch was left out when GLFW_INCLUDE_GLEXT
was originally added, for reasons that are lost to history. The current
versions of these headers seem to co-exist just fine.
Issue reported on IRC.
(cherry picked from commit 309d79376f)
The performance counter API is guaranteed to succeed on Windows XP and
later so there is no need for a fallback.
This removes our last dependency on winmm.
(cherry picked from commit b6834bf2a1)
The native access functions for context handles did not verify that the
context had been created with the same API the function was for.
This makes these functions emit GLFW_NO_WINDOW_CONTEXT on API mismatch.
(cherry picked from commit cca9008db2)
This removes the GLFW_VULKAN_STATIC CMake option and the
_GLFW_VULKAN_STATIC configuration macro and replaces them with the
glfwInitVulkanLoader function, allowing a single library binary to
provide both behaviors.
This is based on the design from PR #1374 by @pmuetschard.
Closes#1374Closes#1890
This removes the global struct member for
vkEnumerateInstanceExtensionProperties, which is only used in the same
function that fetches the function from the loader.
The pattern is now more in line with how other single uses of Vulkan
functions are structures, such as window surface creation.
C does not allow conversions between data pointers and function
pointers.
Yes, the name of the macro is reserved. That's something for a future
commit to fix.
Fixes#1703