Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The weirdest bug I’ve found in a compiler: MSVC 2017

medium.com

Post reply on HN
Print view View original

41–50 of 61 posts

Re: The weirdest bug I’ve found in a compiler: MSVC 2017

#41

Post by stinos »

multani wrote: post #5

I tried remember reading an article on HN a couple of years ago about how MSVC got initial C++ support and added more and more features over time, despite having not being designed with C++ in mind originally. The result was a combination of clever hacks after clever hacks, with the consequence being the reputation MSVC got over time (I'm not saying this is one the consequence shown in the OP) Anyway, does anybody st…

the reputation MSVC got over time

In most places I worked for it actually seemed to have the reputation of a fairly good compiler toolset, unfortunately with just a bit of non-standardness sprinkled on top of it, a bug here and there, and perhaps not the fastest out there. (Which describes pretty much every other compiler out there as well: it's not like there's a perfect one with no quirks whatsoever). But it does the job, the optimization is ok as well, and it usually comes integrated in VS which is top of the line compared to other IDEs.

Re: The weirdest bug I’ve found in a compiler: MSVC 2017

#42

Post by DrBazza »

scarface74 wrote: post #16
multani wrote: post #5

I tried remember reading an article on HN a couple of years ago about how MSVC got initial C++ support and added more and more features over time, despite having not being designed with C++ in mind originally. The result was a combination of clever hacks after clever hacks, with the consequence being the reputation MSVC got over time (I'm not saying this is one the consequence shown in the OP) Anyway, does anybody st…

I'm a two decade Windows developer so this isn't a "M$ Sucks" comment, but Windows itself is a series of hack on top of hack because Microsoft refuses to break backwards compatibility. As much as MS had the reputation of "Windows isn't done until Lotus won't run" back in the day. If you follow some of the MSDN blogs, you'll find the extraordinary hacks that MS has done over the years to keep the most obscure programs…

"but Windows itself is a series of hack on top of hack because Microsoft refuses to break backwards compatibility"

Ironically Sutter was saying in C++ [sic] "we have a good backwards compatibility story". :)

Re: The weirdest bug I’ve found in a compiler: MSVC 2017

#43

Post by iforgotpassword »

userbinator wrote: post #35
realusername wrote: post #34

Earlier quoted context omitted.

Most software on Linux is backward compatible as well, you can get some 90s software, compile it and run it, however it does not have as many hacks as Windows has at the moment to achieve that.

you can get some 90s software, compile it and run it, The "compile" is the tricky part; with Windows, you can get a binary from the early 90s and it will just run. My experience with Linux software is that while the kernel-userspace interface remains stable, userspace is itself full of breaking changes, and software has so many dependencies that trying to compile it quickly turns hairy.

Make that 1985 for windows 1.0

Can't find the site again, but someone figured out you can use an older version of the Borland resource editor to convert the embedded resources to a newer format, than patch the exe header to say it's a windows 2.0 binary and it will run even on windows 10 (32bit version only since of obviously needs the 16bit subsystem).

I was seriously impressed when I saw that.

Re: The weirdest bug I’ve found in a compiler: MSVC 2017

#44

Post by acqq »

jchw wrote: post #17
jchw wrote: post #4

Earlier quoted context omitted.

Didn't you read the rest of the article? They tested with arguments with different names. Further they showed that T was accessible from within the other template when it didn't have a template parameter T, making this even more bizarre. Also, just to be completely sure, I tested it myself. Using X: https://godbolt.org/g/B9YEgZ Showing the template parameter leaking with neither T nor U: https://godbolt.org/g/CKe2wG

Sheesh, I'm not exactly obsessed with internet points but I am kinda curious why I got so downvoted. I wasn't really trying to be condescending, but the article kinda does answer this concern (regarding U being reserved) in a couple ways.

> the article kinda does answer

As you say, "kinda." Obviously, the way I understood it, it kinda doesn't. It does make some simple tests, but fails short from concluding (or clearly stating) anything specific in the text of the article. The way I read the article, it still appears to me that there are some specific names active in the scopes used, the way they are used, and that author's code hints at them.

Re: The weirdest bug I’ve found in a compiler: MSVC 2017

#45

Post by jwilk »

jchw wrote: post #17
jchw wrote: post #4

Earlier quoted context omitted.

Didn't you read the rest of the article? They tested with arguments with different names. Further they showed that T was accessible from within the other template when it didn't have a template parameter T, making this even more bizarre. Also, just to be completely sure, I tested it myself. Using X: https://godbolt.org/g/B9YEgZ Showing the template parameter leaking with neither T nor U: https://godbolt.org/g/CKe2wG

Sheesh, I'm not exactly obsessed with internet points but I am kinda curious why I got so downvoted. I wasn't really trying to be condescending, but the article kinda does answer this concern (regarding U being reserved) in a couple ways.

From the HN guidelines:

Please don't insinuate that someone hasn't read an article.

[...]

Please don't comment about the voting on comments.

Re: The weirdest bug I’ve found in a compiler: MSVC 2017

#46

Post by fyi1183 »

pjmlp wrote: post #19
jchw wrote: post #8

Earlier quoted context omitted.

MSVC has had C++ support for a long time, to be fair. GCC was probably just as bad at first, it just improved more steadily over time. Today, GCC and Clang both seem like very robust C++ compilers, and it doesn't feel like MSVC is terribly far behind (it does feels like it is behind, in my perception, just not far.)

Visual C++ has the best C++ among commercial C++ compilers. http://en.cppreference.com/w/cpp/compiler_support And the table lacks most embedded compilers.

That feels like one of these misleading marketing statements. The real competition are GCC and clang.

But yes, embedded compilers are usually a nightmare.

Re: The weirdest bug I’ve found in a compiler: MSVC 2017

#47

Post by pjmlp »

fyi1183 wrote: post #46
pjmlp wrote: post #19

Earlier quoted context omitted.

Visual C++ has the best C++ among commercial C++ compilers. http://en.cppreference.com/w/cpp/compiler_support And the table lacks most embedded compilers.

That feels like one of these misleading marketing statements. The real competition are GCC and clang. But yes, embedded compilers are usually a nightmare.

They are the competition when one only cares about *BSD, GNU/Linux, Windows systems.

Re: The weirdest bug I’ve found in a compiler: MSVC 2017

#48

Post by digi_owl »

realusername wrote: post #34
justonepost wrote: post #30

Earlier quoted context omitted.

There’s a very good business in maintaining backwards compatibility. Any large enterprise is not going to buy from a company that they can’t rely on having a roadmap that will fix security issues but won’t break their deployed software.

Most software on Linux is backward compatible as well, you can get some 90s software, compile it and run it, however it does not have as many hacks as Windows has at the moment to achieve that.

The CLI stuff, yes. In large part thanks to Torvalds holding everyone to strict rules. Higher in the stack, not so much.

Re: The weirdest bug I’ve found in a compiler: MSVC 2017

#49

Post by SteveJS »

xioxox wrote: post #38
realusername wrote: post #37

Earlier quoted context omitted.

I must admit you are right, it works again on Linux because the API is stable and you have the source, if you take a Linux binary directly from the 90s, there's very little chance it's going to run properly..

Linux has a stable kernel ABI. If you can get hold of the appropriate libraries of the vintage of the executable and set up the library loading correctly, it is possible to run it. Of course if the binary is a.out format, then we can't do this.

Compat in windows was a highly engaged technical problem, in a way that would be considered ‘hack on top of hack’ in linux.

Windows ability to shim is significantly more sophisticated then maintaining a stable abi. It can present a facade of old implementation details to specific programs. Here is a Raymond Chen blog post (2006) on making an app with a ridiculous bug continue to ‘work’ by creating a decoy to compensate for the app bug. He mentions app compat in the ‘immature’ days of windows 95 where they ‘only’ had the ability to use app compat flags and hot patch binaries in memory on load: https://blogs.msdn.microsoft.com/oldnewthing/20060109-27/?p=...

It can be argued that extreme app compat is a bad thing. Paying customers with line of business apps that ‘simply’ continued working never argued that.

Re: The weirdest bug I’ve found in a compiler: MSVC 2017

#50

Post by Narishma »

scarface74 wrote: post #33
justonepost wrote: post #30

Earlier quoted context omitted.

There’s a very good business in maintaining backwards compatibility. Any large enterprise is not going to buy from a company that they can’t rely on having a roadmap that will fix security issues but won’t break their deployed software.

Unfortunately the market for "companies that need to deploy a fleet of Windows computers to run a bespoke app" is shrinking compared to the entire market. I'm thinking UWP is a them attempting to start over.

Isn't UWP still built on top of all those hacks upon hacks the previous commenter mentioned?
Post reply on HN