Bullshit Visual C++ 2005 regression bug
I’m working on building a Win32 static library version of zlib, which uses some .asm files. One of these files, inffas32.asm, contains this line (line 647):
movd mm4,[esp+0]
This line fails to assemble with the following error:
error A2070: invalid instruction operands
I only found one mention of this problem with zlib, an incoherent blog post here. It links to a Microsoft bug report which has this to say:
Microsoft Macro Assembler 8.0, included with Visual C++ 2005 Express Beta 1, refuses to assemble some instructions that were valid under MASM 7.1 included with Visual Studio .NET 2003. Specifically, it refuses to assemble a MOVD instruction with a memory operand with an implied size, and requires that “dword ptr” prefix the memory operand. Although this is ambiguous under AMD64, it is not ambiguous in IA32 and should not be an error, particularly as this behavior is a regression from 7.1 and breaks existing valid source code.
The resolution?
this isnt a bug, rather its syntax that was previously allowed that should not have been. The “fix” here is to use the correct operand sizes in the syntax.
Goddamit, that’s helpful. Sure, the code is technically wrong. But it’s been technically wrong since at least Visual Studio 6.0 some eight years ago, and has worked all this time. You’d think there’d be at least a ‘heads up, we’re about to fuck you’ note somewhere. So now I guess I have to go through and change all the movd instructions to use explicit pointer sizing. Fuck.
UPDATE
It seems there are already Visual Studio 2k3 and 2k5 project files in the contrib\vc7 and contrib\vc8 folders respectively in the zlib source tarball. They seem to work quite a bit better. Still, that doesn’t get MS off the hook for a real dick move.
Tags: Migrated from Drupal, sucks, tech diary, visual c++
May 22nd, 2008 at 10:47 pm
Oh right, blame Microsoft for enforcing standards, which breaks *faulty* code, when the real blame should be on the developer of zlib. Just because a standard was allowed to slide for a while doesn’t mean it’s acceptable to maintain compatibility for it, especially when it was a mistake to begin with.
May 22nd, 2008 at 11:22 pm
Um, the assembly language instruction in question is _NOT_ ambiguous for IA32 targets. It’s not as though we’re talking about the compiler suddenly using Koenig lookup or for-loop scoping rules; this is an assember which assembles code written in a fairly limited vocabulary, suddenly changing that vocabulary without warning.
I have little sympathy for programmers who complain when better implementations of C and C++ standards break their non-standard code (except in cases where the previous compiler version didn’t support the ‘correct’ formulation), but we’re talking about the de factor assembler for the last–what–20 years? There is such a thing as a de facto standard.