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

31–40 of 61 posts

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

#31

Post by schrodinger »

dgellow wrote: post #26
jchw wrote: post #25

Earlier quoted context omitted.

I know I don't have to, but I do anyways; personal choice. First time anyone's really even pointed it out.

I’m not a native English speaker myself, and I don’t live in a place with a majority of native speakers, so maybe that’s why. I got confused reading your comment as I thought that you were talking about something that I missed from the article (a link, or something else), thus I shared this feedback. Though I’m not sure why people downvoted my comment. I haven’t expressed anything against the use of neutral pronouns…

FWIW as a native English speaker I didn’t even notice that they (hah) used they. It sounds natural when you don’t know (or don’t care to emphasize) the gender of the singular person in question. Just trying to be helpful for the next time you notice that construct :)

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

#32

Post by Matthias247 »

acqq wrote: post #3

template using func_type = decltype(U{}.func()); I admit I'm not following all the new stuff that is added to C++. What are that two lines supposed to mean? I don't know what the U{}.func() and using x = decltype() constructs should mean or their names. The names of these and links highly appreciated. Thanks. Moreover, regarding the "bug": if "U" is actually special as an identifier (e.g. some predefined macro or som…

U is a class name, which is given as a template parameter. The braces are the new uniform initialization syntax, which basically means U{} constructs an object of type U. U{}.func() then calls the member function with the name "func" on the constructed object. decltype() returns the type of the contained expression. So I think it should return the return type of the member function. Then "using" assigns that type to an alias, as some typedef.

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

#33

Post by scarface74 »

justonepost wrote: post #30
scarface74 wrote: post #16

Earlier quoted context omitted.

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…

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.

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

#34

Post by realusername »

justonepost wrote: post #30
scarface74 wrote: post #16

Earlier quoted context omitted.

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…

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.

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

#35

Post by userbinator »

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.

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.

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

#36

Post by userbinator »

TwoBit wrote: post #28
TwoBit wrote: post #18

I found years ago that (at least with older versions) VC++ implemented templates essentially as internally generated macros. All the non-standard behaviour they had could be explainined by considering how they would act if they were macros. This bug strikes me as being consistent with that. T is leaking across structs because it is internally #defined and seen by another struct. I think Microsoft has managed to prop…

I just found this statement from Microsoft: https://blogs.msdn.microsoft.com/vcblog/2017/09/11/two-phase... "MSVC previously recorded the body of the template as a stream of tokens and stored that stream away to be replayed at instantiation time. The behavior of MSVC’s template substitution from a recorded token stream somewhat resembled the behavior of macro substitution in that limited analysis was done of a templa…

As someone who is admittedly not an expert in template metaprogramming by any means, thinking of templates as an extension of macros feels like the intuitive and simpler way compared to the more complex two-phase algorithm, so it's no surprise that MSVC did it too... then again, I prefer simpler languages (like C) and see the difficulty of implementing the standard as a sign that its complexity may be too high.

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

#37

Post by realusername »

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.

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..

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

#38

Post by xioxox »

realusername wrote: post #37
userbinator wrote: post #35

Earlier quoted context omitted.

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.

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.

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

#39

Post by multani »

cesarb wrote: post #27
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…

Perhaps it was one of these two? https://blogs.msdn.microsoft.com/vcblog/2017/09/11/two-phase... https://blogs.msdn.microsoft.com/vcblog/2015/09/25/rejuvenat...

That might be the one from 2015 that I was looking for! Thanks!
Post reply on HN