back to article Microsoft admits critical .NET Framework 4.6 bug, issues workaround

Microsoft has published a workaround for a critical bug in the .NET Framework 4.6 that can result in incorrect parameters being passed, with unpredictable results. Program manager Rich Lander has blogged about the problem. According to Lander, it can affect any .NET 4.x application, but once the .NET Framework 4.6 has been …

  1. Anonymous Coward
    Anonymous Coward

    Nothing to worry about, move along

    This issue is narrow in nature. [...] We have not identified an exploit, but are pushing the change through our process at the same pace as we would an exploit.

    Meaning: We didn't find any exploit, so the fix shouldn't be considered urgent. Come on, we only borked the compiler, that's no problem at all, and it doesn't even affect that many programs. Yet we'll still fast track the fix, out of charity.

    That's too kind of you dear sirs. It's not as if compilers were by far the most critical pieces of software.

    1. Anonymous Coward
      Anonymous Coward

      Re: Nothing to worry about, move along

      Take any medium size (or larger) application written in C/C++ and compile it with gcc -o3. Result: Broken application.

      .NET has a *far* better history, even including this bug, of having a functional optimising compiler.

      1. Anonymous Coward
        Joke

        Re: Nothing to worry about, move along

        >Take any medium size (or larger) application written in C/C++ and compile it with gcc -o3. Result: Broken application.

        I've just tried it. The program worked fine. The only odd thing was the output file from gcc was called 3.

        1. AdamW

          Re: Nothing to worry about, move along

          O

          1. Anonymous Coward
            Anonymous Coward

            Re: Nothing to worry about, move along

            O

            Yes, that's what most of us say when someone's been foolish enough to mess with that flag without understanding it.

            (Speak from experience: try compiling glibc with -O3 and see how far you get. Did it once with Linux-from-Scratch, never again.)

            1. FireBurn

              Re: Nothing to worry about, move along

              I've used -Os -O3 and the new -Ofast - there's very few bits of software that break with those. The only packages that I've ever seen having issues are the gcc and glibc. On Gentoo they're automatically filtered out on sensitive packages. I've since switched back to -O2 purely for the time saved during regular compiles. The only quantifiable speedups I saw with -O3 was in Chromium - it scored better in the peacekeeper benchmark but only marginally. It seems -march=native is far more useful for achieving speedups

              1. Michael Wojcik Silver badge

                Re: Nothing to worry about, move along

                In my experience, -O3 is often fine for C or C++1 programs that actually conform to the standards and don't rely on undefined behavior, or make incorrect assumptions about implementation-defined behavior. Of course, the vast majority of C and C++ programmers are manifestly incapable of writing such code.

                1There is no language called "C/C++". C and C++ are very different languages. Of course, here we're talking about GCC, which also implements a language often called "C", but which is substantially unlike C.

  2. Anonymous Coward
    Anonymous Coward

    Just another day at the aslym

    Does anyone actually think Windoze is worth using or remotely secure?

  3. Henry Wertz 1 Gold badge

    Optimization error

    "Take any medium size (or larger) application written in C/C++ and compile it with gcc -o3. Result: Broken application.

    .NET has a *far* better history, even including this bug, of having a functional optimising compiler."

    This is a ad hominem. You compare .NET's default, out-of-the-box behavior with a compiler option that is generally not recommended (I actually can't find this recommendation any more, but it used to be -O2 was the highest recommended, with -O3 being a "it'll be faster but make sure it actually works" optimization.) That said, .NET does have a pretty good track record regarding compiler errors and such. This does point to the big concern of Windows 10 autoupdates... you could read about a broken update, decide "Well, good thing I read about it, I'll not install that one", then realize "Whoops, I have no way to disable automatic updates!". Nice.

  4. Sirius Lee

    It's a real shame you didn't credit or link to Nick Craver's blog. Nick the person who identified the issue as a result of problems on the Stack Overflow web site. In the post he describes the problem in detail so developers, not a Microsoft program manager, are able to determine if there is a problem to be concerned about.

    http://nickcraver.com/blog/2015/07/27/why-you-should-wait-on-dotnet-46/

  5. Michael Wojcik Silver badge

    F#

    It's more of an issue for F# programmers because F# programs, like those written in other languages in the ML family, are much more likely to make use of tail call optimization (TCO). Tail recursion is perhaps the quintessential pattern of functional programming, and so TCO is far more prominent in functional languages like F#.

    And this is a TCO bug in RyuJIT.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like