“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)
The problem with the comment is it does not make ownership of the next steps clear. The maintainer should've either taken the ball ("I will report this to...") or made it clear that the reporter should hold the ball ("We can't fix this here. You should report it to..."). Instead they used the passive voice ("The issue should be reported to..."), which means no one owns it, which means it won't be done, which is a bad way to handle a bug report.
How you choose to resolve it is up to you. You might implement a fix in your code to handle the bug case until the dependency is fixed.
Instead means "this isn't our bug, it's the underlying library."
The libraries you rely on are part of your product. You own the issues that bubble up from them.
A much much better reply for the maintainer would've been: "The root cause looks to be X, I'll submit a ticket and make sure a fix makes it into our build."
they didn't test that they just assumed that since they call a library function the library function must be the root-cause. This is classic bug-punting.
OP said it quite clearly and so did you: that it's the reporter's job. It's the maintainer's job to put in the bug report now.
Bug reporter might not care that much and not bother opening another bug report, and this looks like a pretty bad bug.
https://github.com/dotnet/runtime/issues/117233#issuecomment...
You’re quoting a community contributor and this is not a firm stance held by MS themselves. He should probably not have posted that because it’s misleading. They even have a tag to triage these kinds of issues.
The comment isn't blaming the reporter for not doing that.
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 think it's _too_ social for bug reports and questions. I'd prefer a forum or GitHub issues for that kind of thing.
Or maybe I'm just getting old.
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?
(Comments blame it on UCRT, not .NET but… that doesn’t matter much to me.)
This is unfortunately an actual quote I got from Claude Code after having it write a unit test for me.
It ended up mocking the entire method it was supposed to test, resulting in the unit test essentially only testing itself.
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"
Finding the right contact even for employees inside the beast is challenging and a skill all its own.
But that is way more normal for microsoft, because it's about redundant products that get merged eventually. What's not typical is internal dependencies being exposed, the case above were many MSFT teams/products in the same tier, the case in this article is many MSFT teams/products in a single vertical, at different tiers of the supply chain.
It's possible that this is more a feature of open source, this being an open source MSFT product (.NET core) and the report having been filed through an open source channel (github issues). I think that if the issue were submitted to some account manager or customer service rep through a channel linked to a paying customer account, the response would have been very different.
But you cannot expect a quality customer service response if there's no $ being paid to the maintainers. Whether it be Microsoft or whatever FOSS project.
That said, maybe a slight change like, "I'll open a ticket with the other team" instead of "you should open a ticket with the other team" makes all the difference. But like I said in another comment, if you open a ticket on github, you aren't paying for that support, you should aim to have a commercial relationship with Microsoft and then raise the issue through that commercial channel.
Otherwise you have no recourse to complain, you are getting everything as-is.
It's like the first example you see when you start learning about unit tests as a concept.
I don't see how it gets past the test suite though.
https://techcrunch.com/2025/04/29/microsoft-ceo-says-up-to-3...
So that is the result.
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
Surely math libraries and optimizations have been a solved problem for the last 20+ years.
For instance, with it, you can double the volume of a body by looking at it from a weird angle.
A lot of set-theory research is looking into the consequences of various axiomatic assumptions.
Sweet.
