“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.
You can fix it by handling the erroneous output from your dependency, or switching out your dependency, or submit a fix to the dependency, or asking them to fix it.
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.
> 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.
In this specific case I absolutely agree with you, but if going outside the thread on GPs point, I am way more lenient towards (non commercially backed) OSS projects. I'm usually using the product because no one other than the volunteers are doing it, and if I want something fixed, I might have to put in some work to dig and pinpoint the issue to help a fix along, put in a PR myself, or accept it being broken for a while until someone makes the (unpaid) time. And that's ok, or at least a reality for a lot of OSS.
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.
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'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.
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.
It sounds like your definition of TDD is regression tests + user acceptance test and I've already agreed that those are good things, we seem to just disagree that is TDD is generally practiced in this manner - though you've only given me your personal anecdote. I made a generalization based on an observed pattern of behavior at a rather large scale, I will assume that you do TDD as is intended, but I already assumed individual counters to my generalization existed so your anecdote has changed nothing. The question remains, does the generalization hold for the general case. Like the USSR made a valiant effort to achieve true socialism Microsoft made a valiant effort to implement true TDD before giving up in 2014.
The definition is you write or amend a test before making the code change that makes it pass.
That's it. It says nothing about the type of test you write. Personally i do it with literally every type of test that i write - acceptance, integration, unit.
If you write a decent test, yes, TDD is always valuable. If you TDD with shitty tests, not so much, but that isnt really an issue with TDD.
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.
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.
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.
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."
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.
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”
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 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).
I disagree with the comment
“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.
Of course. They chose to resolve it by saying the underlying software should be fixed. That seems perfectly fine to me.
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.
That's not a resolution, that's ignoring the bug.
No, it isn't. It's directing the bug to the people who are able to fix it.
You can fix it by handling the erroneous output from your dependency, or switching out your dependency, or submit a fix to the dependency, or asking them to fix it.
No its not, stop being obtuse on purpose.
This issue is the word "instead".
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?
The latter
>The bug is in an underlying library
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.
If you can't hunt it, punt it!
If a library has a flaw that big, it is a bug to use that library.
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.
> What do you disagree with, exactly?
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.
> 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.
From the OP:
> It’s not the job of a bug reporter to figure that out
What’s ambiguous about this statement?
Bro is a Microsoft employee. He should say "thank you for the bug report", and open a bug in the underlying library if that is the correct place.
Bug reporter might not care that much and not bother opening another bug report, and this looks like a pretty bad bug.
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.
In this specific case I absolutely agree with you, but if going outside the thread on GPs point, I am way more lenient towards (non commercially backed) OSS projects. I'm usually using the product because no one other than the volunteers are doing it, and if I want something fixed, I might have to put in some work to dig and pinpoint the issue to help a fix along, put in a PR myself, or accept it being broken for a while until someone makes the (unpaid) time. And that's ok, or at least a reality for a lot of OSS.
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.
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'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.
Apply the "reasonable person" standard.
> No idea, I can't read their mind.
Mind-reading is not necessary to predict how people will react to certain patterns of behavior.
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.
Just posting to say everything is fine. It works to report this way too, via .NET maintainers. It is very common to do this as well.
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.
That "instead" later got swapped for "in addition" in a clarifying comment that makes this feel a lot less gross afaic
>It’s not the job of a bug reporter to figure that out
The comment isn't blaming the reporter for not doing that.
It reads the opposite to me. I absolutely read it as "you reported this to the wrong people".
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.
It is at the very least putting the onus on the reporter for correcting it, which is not how it should be done here.
[dead]
> 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.
Or maybe I'm just getting old.
I've heard people moan that software is getting exponentially worse. Maybe they're right after all /joke
Clearly the issue is real and not imaginary
There are no imaginary numbers insolved in this bug, however.
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.
Tell that to the compiler.
I see what you did there
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.
I think it has more to do with the people than the tools.
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!
An exponentially astute observation.
Don't be so negative.
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?
I really want to know how this could have passed CI testing.
(Comments blame it on UCRT, not .NET but… that doesn’t matter much to me.)
“Oh, I can see the test is failing. Let me fix this by adjusting the test to expect the currently returned value.”
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.
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.
TDD only really works if the test in some sense mirrors the specification.
Sometimes people manage it in which case it resembles a mini superpower but mostly they do not.
If it mirrors the spec then few people would change it to be wrong to make the test work.
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.
It sounds like your definition of TDD is regression tests + user acceptance test and I've already agreed that those are good things, we seem to just disagree that is TDD is generally practiced in this manner - though you've only given me your personal anecdote. I made a generalization based on an observed pattern of behavior at a rather large scale, I will assume that you do TDD as is intended, but I already assumed individual counters to my generalization existed so your anecdote has changed nothing. The question remains, does the generalization hold for the general case. Like the USSR made a valiant effort to achieve true socialism Microsoft made a valiant effort to implement true TDD before giving up in 2014.
The definition is you write or amend a test before making the code change that makes it pass.
That's it. It says nothing about the type of test you write. Personally i do it with literally every type of test that i write - acceptance, integration, unit.
If you write a decent test, yes, TDD is always valuable. If you TDD with shitty tests, not so much, but that isnt really an issue with TDD.
Sounds like a “no true Scotsman” fallacy.
It's not. "Doing C before doing Y is beneficial but requires you to be competent at C." is not a no true Scotsman.
Because AI is learning from humans and half of coders suck.
Now I understand how people who let LLMs write their code for them come to believe it boosts their productivity. /s
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.
(Please hold while we transfer you to the UCRT department, your call is very important to us)
Maybe this is a new optimization, and AI wrote the tests.
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.
Off by 2, not so bad
The "off by 1" errors grow exponentially these days.
Worse than that, since the nth power of 1 should still be 1. Except when you're running Microsoft-ware, of course.
Looks like complex numbers are much simplified on Windows 11.
They convert the arguments to complex, do it right and the error is at the back conversion step!
How does the OS still function with a basic bug like this?
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)
The bug is for an exponent of 2. The base is -1.
They mean power of -1.
Most critical OS functionality will use integers, not floats. And I'd expect most programmers to write squaring a float as `x * x`.
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.
There was an article some time ago where someone ran doom with progressively more incorrect value of pi
What critical OS functionality would this break?
30% of all code by Microsoft is written by AIs:
https://techcrunch.com/2025/04/29/microsoft-ceo-says-up-to-3...
So that is the result.
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.
Should we be surprised that Microsoft doesn't know maths? Was the code for that generated by an LLM?
Anyone got a link to the actual OS bug that caused this? I would love to see an explanation of how it happened and what the code looked like.
Side note.
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"
Microsoft is a many headed beast.
Finding the right contact even for employees inside the beast is challenging and a skill all its own.
I'm more used to hear this kind of 'it's not our fault' crap from state bureaucracies not companies that want me to pay them...
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.
Bureaucracy sets in before statehood.
Large enough companies are states - period. Apple is a state. So was Standard Oil.
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!
> because they can't afford a Mac
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.
Yes, I have years of experience with both and macOS is way less of a user-hostile experience. People buy Apple products because they like them.
Because they like them better than Windows actually.
They're both crap, Apple is less crap.
This post typed on a macbook pro.
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.
I am sorry if it sounded like I was suggesting it was not their fault.
I was simply stating fact, without any particular opinions on the matter of fault.
For stuff where they take money, like Azure, Microsoft has clearer lines of support. .NET and Windows are loss leaders.
Which is exactly why the employees need to be the ones shepherding these reports to the right place.
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 maintainer is not a Microsoft employee. For what that’s worth.
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.
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."
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.
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”
Reminds me of this 2005 paper: https://www.sciencedirect.com/science/article/abs/pii/S01679...
Reminds me of the Pentium FDIV bug from 1994.... a half-billion-dollar 'ouch' for Intel were many hard lessons were learned.
Surely math libraries and optimizations have been a solved problem for the last 20+ years.
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
Microsoft moved to a Universal CRT (UCRT) around Windows 10, both C# and C++ are calling into the OS UCRT there.
One bug to rule them all...
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 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”.
How did this happen? This feels like the easiest function in the world to write a unit test for?
This.
It's like the first example you see when you start learning about unit tests as a concept.
The good thing is, if (-1)^2=-1, we can prove anything! NP=P, every program halts, axiom of choice - math just becomes so much easier.
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.
Yes. Prominent example is the axiom of choice. There was a LOT of discussion about it by mathematicians. https://plato.stanford.edu/entries/axiom-choice/
For instance, with it, you can double the volume of a body by looking at it from a weird angle.
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).
The mathematics equivalent of the any% speedrun community?
It’s not sub-field. It’s a technique. You relax or change axioms defining your thing and see what happens.
Paraconsistent logic looks into logical systems that allow contradictions.
A lot of set-theory research is looking into the consequences of various axiomatic assumptions.
TIL osu is open source
So they are vibecoding MSVC now?
Sweet.
Yes, they do:
https://techcrunch.com/2025/04/29/microsoft-ceo-says-up-to-3...
Ahaha, amazing article! Let's see which company goes down deeper in 2030
Since this seems to be in ucrt and hence a much more widespread problem, it would be nice to know the CRT/Windows versions affected