“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)
What do you disagree with, exactly? The bug is in an underlying library, so it should be reported to that library. That all seems correct to me, I don't see what there is to disagree with there.
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.
If your software has a bug, it’s your bug. If the root cause of the bug in your software comes from a direct call into some dependency, that’s immaterial to the users of your software. Your software is incorrect, so your software has a bug.
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.
The responsible thing to do would be to report the bug to the upstream project and keep the issue open pending the underlying issue's resolution.
This is a broader cultural thing. In large organizations there is a tendency toward deflecting as much responsibility as possible onto other teams. In part it's a lack of resources, but it's also a result of individual contributors not being willing to take ownership of the product they work on.
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."
Unless the documentation says that Math.Pow just returns the result of calling some other code (it doesn't do that), the bug is both in the Math.Pow and underlying library. It should be reported and tracked in both.
But should it be the responsibility of the person reporting the bug in Math.Pow, or the devs maintaining Math.Pow sees it is part of the underlying library and makes the report?
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.
You are going to have a very short, frustrating career in software if that's your position. Bugs happen, report them, get them fixed, chill out, and don't be a dick.
I’m going to give a HARD disagree with this type of hand waving for a bug in pow().
First, how was a change allowed in such a fundamental function without significant justification and validation. It’s exponentiation. That’s like saying you want to fix multiplication. Sure, but it better get higher scrutiny that a higher-level function.
Second, where is regression testing. It’s a trivial function to write tests for, which means MS never created real test plans for basic UCRT functions. This is where the outrage should placed.
> OP said it quite clearly and so did you: that it's the reporter's job.
I don't agree that it was stated clearly. That's the whole point of my comment. Leaving it unclear is bad, tasks should always have an unambiguous owner.
This. And that's how it should work whether or not it's a Microsoft application.
Users report bugs to the team working on the user application. If the bug is actually in a component that application uses, then it's that team's responsibility to report it upstream, not the user's.
In theory and definitely how it should be for commercially backed projects. For volunteer OSS though (and commercially backed) maintainers are frequently not going to do that in my experience.
I don't think being commercial or volunteer affects this. The end user shouldn't report it upstream, not just because that's putting more burden on the user than is called for, but because the end user likely doesn't know enough about how the component is used in order to make a good bug report or answer questions the upstream component may have.
That some OSS devs don't work that way isn't really important in terms of this point. If the project isn't going to address the bug, they should just say so without implying the user did something incorrectly.
I agree that's the ideal solution in a vacuum, but I don't know this person's responsibilities regarding the projects in question, so I don't want to make assumptions about what they can or should do.
If their job isn't to handle bug reports against .NET, what are they doing writing confidently about what should happen as a response to a bug report against .NET?
I am taking no stance about their responsibilities. What I am saying is they should have made the ownership of the next steps clear. Who the owner is depends on their responsibilities, which I don't know.
It was clarified on the thread that that person was NOT a Microsoft employee and just a volunteer. That completely changed my perspective on the situation.
It's going to be interpreted, and is probably meant, as saying that the person who filed the bug should close this report and open a new one in the right place.
Since the comment you responded to already complained about use of passive voice...
It's going to be interpreted BY WHOM to say that? Other .NET developers? Yeah, maybe, at least some of them. By the submitter of the original bug? No idea, I can't read their mind.
By approximately everyone. Passive voice saying something should be done differently, in reply to someone doing something, is saying that person should do it differently.
reminds me of when i had a job working on a company that had its own OS (which was an extremely outdated proprietary FreeBSD fork) and we spent more time arguing about who's fault everything was than solving problem. I used to love low-level programming until I realized that in the corporate world (i assume/hope this does not apply to open-source communities) the people who get ahead are the people who can master the art of jettisoning responsibility so that they're always the guy who just implemented the hot new feature and management thinks the people who actually have to make this stuff work are all incompetent and lazy because it takes 2-4 weeks to untangle all the heap corruption and race condition bugs and ultimately come up with a meager 10-line patch to prevent the kernel panic.
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 clear. It can be read as blaming the reporter, or it can be read as telling someone else who works on .NET (who?) to open a bug report against UCRT.
> 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
Discord also has a kind of culture I don't love connecting to for misc environments. I'm sure most are fine, but I've joined software related discords where people are having oddly NSFW chats. They've always been in different channels, but why does this software project need a NSFW channel?
I think it's _too_ social for bug reports and questions. I'd prefer a forum or GitHub issues for that kind of thing.
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)
Although, if (-1)^2=-1, then the question that generates imaginary numbers doesn’t even come up, right? Clearly the square root of a negative is well defined.
You're joking but we went from the Ada "contracts and pre/post conditions" to the ReactJS monstrosities instead on improving the whole thing and being more strict.
that's what the comment means we as people went from picking Ada to ReactJS
of course we also went from having no Rust and no TypeScript and only a few hundred thousand semi-academic people having some knowledge of programming to hundreds of millions of people doing some tutorial/bootcamp/cert/degree, or even built something, or actively learns, or right now works as a professional programmer.
(un)fortunately Ada was not able to grow to became the default tool for all these jobs that all those millions of people did or wanted to do when they did/do programming.
JS/ECMAScript is evolving, things are getting better!
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?
Sounds very human. I experienced some junior devs who grew up with TDD and would often just tweak their code to pass their tests without stopping to understand their code at a fundamental level - essentially development through trial and error. Since they were also the ones writing the tests the core assumptions went into both and because they did so without thinking they were more likely to have errors. The test being wrong was more than likely and in those cases it would make sense to fix the test output.
AFAIK TDD culturally occurred at the same time as the push for 100% test coverage. So we would end up with code bases that were 90% test code and 10% actual code, every individual method had many tests. This meant for every code change there was a 10x test change so test timelines dominated dev timelines, there was a push at the time to expand the test org to be 2x the size of the dev org. AFAIK at MS that was abandoned and the test org was folded into the dev org and now the devs are expected to write and maintain their own tests.
I have only seen TDD used poorly, as a crutch, an alternative to thinking deeply about the problem space. If it can be done well I have not personally seen it. Perhaps SQLite, but such projects are an oddity.
To me tests at the spec level are largely user acceptance tests which are indeed very useful.
The push wasn't to test every individual method but to test every individual code change. This confusion you had was shared by many others and caused havoc because if you unnecessarily couple every single interface in the code base to a test then every change breaks a test. This became worse for many people than not writing tests at all.
>I have only seen TDD used poorly, as a crutch, an alternative to thinking deeply about the problem space. If it can be done well I have not personally seen it. Perhaps SQLite, but such projects are an oddity.
Theyre not that odd. I've applied it to every type of code base I've come across.
>To me tests at the spec level are largely user acceptance tests which are indeed very useful.
Where I use TDD the tests are exactly like this - written at the highest level possible using a shared framework that integrates sophisticated fakes which carefully balance realism, speed and flakiness. They all follow roughly the same pattern across the code base and that pattern mirrors the spec scenarios.
Where I see TDD used by people who complain about it they usually think the idea is to write a test for a class because they're thinking about writing a class. It is generally taught badly.
I would definitely expect some kind of test like -1^2 == 1 for such an important SDK, even more if it impacts C++ too. Well, they hopefully have now written this test.
Maybe its a bug in their telemetry? They have to pass the parameters to azure to data-mine customer activity and azure accidentally returned the incorrect result.
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"
When a company has its street named after themselves and a fleet of buses to carry employees to the company, one can start considering Microsoft as a state with all the necessary bureaucracy.
Microsoft is long past the point of realizing they don't need to make their product good to keep users. Everyone who uses Windows is stuck using it because of software lock-in, or it's what's on the laptop their job provides, or because they can't afford a Mac. Outside of niche communities, there aren't a lot of "Windows fans" out there these days.
They'll gladly harvest your data whether you like them or not!
Ha, as if the situation with macOS is much better? The OS space is a (lopsided) duopoly, both Microsoft and Apple know it and have pulled down their sleeves long ago.
Large companies are the same for the same reasons, the relationship between you paying them and their personal benefit is so incredibly remote that it might as well not exist.
Yup, definitely has felt that way for years, they do try to consolidate but it takes years. When I was trying to setup something for customer support I was navigating all of their redundant products, Teams, Skype, Skype for Business (different thing), Lync.
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.
The buck is passed all of the time, it simply happens internally and out of sight of the customer. In this case, it looks like an open source component managed by a commercial company. They could do everything out of sight, but the open source world also encourages transparency.
Right, as a customer you always prefer that it happen out of sight, but I guess these are the very tradeoffs of choosing open source software, you can't get the best of both worlds.
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.
I think a big part of the transparency was to help clean up this very mess, motivate developers to do the right thing or face public ridicule. The public is not in any org chain, we don’t get performance bonuses, we’re not incentivized to hide issues from upper management, it is very much the opposite. Having this out of band communication is incredibly valuable and helps keep the reporting chain honest. Someone somewhere inside MS will use this example in an effort to fix the process, much easier to say 30 random internet people with no motivation the lie or collude all agree that this is unacceptable than to say “I think this is unacceptable”.
It's easy to have both transparency and proper handling. "Thank you for the report. This issue is actually in the underlying Whatever library. I've passed it along to that team."
I don’t think there is much systems code that needs an exponent of -1, maybe none that needs exponents at all (aside from 2^n, which has opcodes, not C functions)
Due to how windows manage dependencies, you can have different versions of same library all the way back to windows xp days. It's not necessary other software on the computer will hit the bug on this version of library.
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?
In fairness, the general power function might well be complicated. Dealing with fractional base and exponent, signs (-1^2 makes sense but -1^0.5 doesn't in real numbers). I don't know how that works in code but I can see how this gremlin sneaks in.
I don't see how it gets past the test suite though.
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
Probably isn't a link between the OS and compiler. the OS kernel is responsible for saving and restoring the floating-point environment every time there's a context switch, my hypothesis is that something went wrong there.
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”
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”.
Joke aside, is there a field (or sub-fields) of mathematics that just... studies what breaking some axioms would do and where would it lead? This seems both completely stupid but also potentially fascinating at the same time.
That's a very misleading description of Banach-Tarski.
You need to break up the body into a few (very weird) pieces and maneuver them (via only rigid motions - rotations and translations).
“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)