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

51–60 of 61 posts

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

#51

Post by jchw »

pjmlp wrote: post #47
fyi1183 wrote: post #46

Earlier quoted context omitted.

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.

Well, and Android and iOS and many microcontrollers (well, often a shitty GCC fork in that case but still) and way more platforms (OpenBSD, Minix, HP-UX, Solaris, VxWorks, bare metal) and architectures (Alpha, ARM, AVR, x86, m68k, microblaze, MIPS, PDP-11, Risc-V, SPARC, VMS) than that, not including third party ports in SDKs.

Yeah, I get that with embedded, it's a crapshoot. However it's probably not ridiculous to say that GCC ports to microcontrollers is not terribly uncommon, either.

GCC and Clang certainly are a lot more useful than for just that tiny range you listed. The reality is they probably cover more platforms than any other individual compiler.

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

#52

Post by pjmlp »

jchw wrote: post #51
pjmlp wrote: post #47

Earlier quoted context omitted.

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

Well, and Android and iOS and many microcontrollers (well, often a shitty GCC fork in that case but still) and way more platforms (OpenBSD, Minix, HP-UX, Solaris, VxWorks, bare metal) and architectures (Alpha, ARM, AVR, x86, m68k, microblaze, MIPS, PDP-11, Risc-V, SPARC, VMS) than that, not including third party ports in SDKs. Yeah, I get that with embedded, it's a crapshoot. However it's probably not ridiculous to s…

When I was involved in mainframe or commercial UNIX projects we always used the OS vendor SDK, hence why I left them out of my list.

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

#53

Post by slededit »

Narishma wrote: post #50
scarface74 wrote: post #33

Earlier quoted context omitted.

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?

Yes, but it does a reasonable job of hiding it.

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

#54

Post by scarface74 »

Narishma wrote: post #50
scarface74 wrote: post #33

Earlier quoted context omitted.

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?

But it should allow easier compatibility with lighter weight versions of Windows.

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

#55

Post by digi_owl »

SteveJS wrote: post #49
xioxox wrote: post #38

Earlier quoted context omitted.

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 compensa…

https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...

Simcity supported in Win95 by allowing a use-after-free bug (if i am reading it right) to continue working.

You get something similar in Linux by how once a userspace facing API is in the wild, the API stays, bugs and all, in case something, somewhere, use that specific behavior.

A newer API will be introduce alongside the "broken" one however, with future code highly incentivized to use the newer API.

Sadly that level of stringent API behavior is seen not as a virtue but as a burden by higher layer devs. Often to the point that the refuse to work with Torvalds after being berated for their lax attitudes, and dream of the day he retires...

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

#56

Post by digi_owl »

iforgotpassword wrote: post #43
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.

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.

> 32bit version only since of obviously needs the 16bit subsystem

And afaik, MS only retired the 16-bit subsystem because AMD64 can't switch between 64 and 16 bit modes. You can either run it in 16/32 or 32/64 modes, but not 16/32/64.

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

#57

Post by digi_owl »

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.

Yeah userspace mess is one i lament getting to know, because it has soured me on the whole Linux-on-desktop thing.

Frankly that part is a large contributor to "consumer" Linux never got any traction beyond Google going all out and making their own (Android and ChromeOS), while the DE people keep "polishing" the UX by introducing yet more dependency kudzus.

One example on the top of my head is udisk. First there was udisk1, that had a CLI interface as well as a dbus api. Then came udisk2 that trashed the CLI interface and introduced a new dbus api. And now there is probably some equivalent of udisk3 living inside systemd that has yet another dbus api.

And all this for what? Mounting and unmounting removable media...

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

#58

Post by TwoBit »

userbinator wrote: post #36
TwoBit wrote: post #28

Earlier quoted context omitted.

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.

There's a reason why templates work like this. If they didn't work like this then template specializations that you write can break somebody else's code which is dependent on the template behaving a certain way.

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

#59

Post by lmkg »

iforgotpassword wrote: post #43
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.

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.

The following is a video of someone installing Doom II on DOS, upgrading the operating system in-place 11 times, and running Doom on Windows 7 (around 24 years of upgrades).

https://www.youtube.com/watch?v=vPnehDhGa14

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

#60

Post by userbinator »

digi_owl wrote: post #56
iforgotpassword wrote: post #43

Earlier quoted context omitted.

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.

> 32bit version only since of obviously needs the 16bit subsystem And afaik, MS only retired the 16-bit subsystem because AMD64 can't switch between 64 and 16 bit modes. You can either run it in 16/32 or 32/64 modes, but not 16/32/64.

Not really: https://www.dkia.at/en/node/180

Interesting enough you can still mark a code segment as 16 Bit and the CPU will execute it in 16 Bit mode.

https://www.wine-staging.com/news/2016-02-10-blog-wine-16bit...

The tricky part is that a LDT entry also contains flags which define if a segment contains 16 bit, 32 bit or 64 bit code. If you change to a segment, the CPU will automatically start interpreting the code inside the segment according to this value.

In other words, 16, 32, and 64-bit code can all coexist simultaneously and the CPU can switch between those automatically --- MS just decided not to implement it. Linux with WINE does, however.

Post reply on HN