This happens in both C# and C++ according to the report, but what's the link between OS and compiler here?
As far as I remember from days when I used Windows, the version of your visual studio (which has the compiler and standard libraries) was not related to the build of your operating system
One of the advantages of using proprietary packaged software is supposed to be a unified support and product.
In this case the maintainer redirects the issue to some other team and passes the ball as if it were an open source project with 50 dependencies with thin responsibilities "no, if there's an issue with a button, you should report it to GUI-button, we do GUI-form and we just pass the button generation to their library"
“Both Math.Pow and std::pow invokes the pow function in UCRT, which is shipped with Windows. The issue should be reported to MSVC instead”
It’s not the job of a bug reporter to figure that out and to verify that nothing goes wrong in setting up stuff for invoking that function or in getting its output back into the C# world.
That’s even more true because the dynamic nature of .NET code makes it far from easy to verify by inspection that that function is just calling the pow function in UCRT. The C# compiler might do constant folding wrong and there might be several ways in which the runtime compiles the CLR code (fast compilation to start running it quickly, slower compilation that produces faster code later if it turns out to be called a lot, etc)
No idea why this happened. Perhaps Math.Pow(x,y) was implemented as 2**(y*log2(x)) without writing special code to deal with the case where x is negative real and y is integer?
From the response it is already fixed; no details on cause unfortunately: “This uCRT bug has been already reported through another channel a week ago and it got fixed since
(OS #58189958: pow(-1, 2) returns -1). It might take a while to be available in the public insider builds”
> If you need to contact us better, joining the osu! Discord server would be best
I really dislike how Discord is slowly eating up the web and being used as the primary channel for communication, when most of the community resources resides in their Discord, it makes it hard for me to find relevant information through the web thanks to Discords lock-in
osu! does have a very active github + active official forums, but I assume Joehu suggested Discord because messengers allow for quicker turnaround in cases where publicly documenting the issue and the resolution of it isn't necessary (which is the case here as the issue is on the Microsoft side of things)
From the most recent issue comment: “This uCRT bug has been already reported through another channel a week ago and it got fixed since
(OS #58189958: pow(-1, 2) returns -1). It might take a while to be available in the public insider builds”.
I'm surprised that an optimizing compiler lets this case even hit the general `pow` runtime function. I'd have expected it to replace this call by `x * x` so it doesn't hit the expensive general `pow` function.
I find it strange as well that no unit test caught this. Squaring a negative number is definitely a case I'd expect to be covered. Perhaps compiler optimization made this case work in the unit test, allowing the runtime function to break? And then it broken in .net where the JIT compiler is dumber than the C++ compiler?
24 comments
[ 112 ms ] story [ 102 ms ] thread(Comments blame it on UCRT, not .NET but… that doesn’t matter much to me.)
As far as I remember from days when I used Windows, the version of your visual studio (which has the compiler and standard libraries) was not related to the build of your operating system
One of the advantages of using proprietary packaged software is supposed to be a unified support and product.
In this case the maintainer redirects the issue to some other team and passes the ball as if it were an open source project with 50 dependencies with thin responsibilities "no, if there's an issue with a button, you should report it to GUI-button, we do GUI-form and we just pass the button generation to their library"
“Both Math.Pow and std::pow invokes the pow function in UCRT, which is shipped with Windows. The issue should be reported to MSVC instead”
It’s not the job of a bug reporter to figure that out and to verify that nothing goes wrong in setting up stuff for invoking that function or in getting its output back into the C# world.
That’s even more true because the dynamic nature of .NET code makes it far from easy to verify by inspection that that function is just calling the pow function in UCRT. The C# compiler might do constant folding wrong and there might be several ways in which the runtime compiles the CLR code (fast compilation to start running it quickly, slower compilation that produces faster code later if it turns out to be called a lot, etc)
I really dislike how Discord is slowly eating up the web and being used as the primary channel for communication, when most of the community resources resides in their Discord, it makes it hard for me to find relevant information through the web thanks to Discords lock-in
I find it strange as well that no unit test caught this. Squaring a negative number is definitely a case I'd expect to be covered. Perhaps compiler optimization made this case work in the unit test, allowing the runtime function to break? And then it broken in .net where the JIT compiler is dumber than the C++ compiler?
Sweet.
https://techcrunch.com/2025/04/29/microsoft-ceo-says-up-to-3...
So that is the result.