Hacker News new | past | comments | ask | show | jobs | submit login

The bug has been in the wild for 8 years, so there are almost certainly customers who have VBA scripts that rely on that behavior. Microsoft puts a lot of emphasis on backward compatibility (or at least they used to), so I think there will be some internal debate on whether fixing the bug is more or less disruptive than just leaving it in.



Fix or don't fix aren't the only two options. The third option is to provide a fix that can be enabled or disabled by compiler users as needed.

For maximum backward compatibility, the fix could be disabled by default. But enabling by default still provides a path to backward compatibility with a small amount of manual work for those who need it.

For those who don't want the broken behavior, it might be a hassle to have to enable the fix, but that's still much better than not having a fix and having to write crazy code as a workaround.

I don't know VBA, but as a guess, the #Const directive (https://docs.microsoft.com/en-us/office/vba/language/referen...) for compile-time constants looks like it could be a reasonable way to implement a switchable compiler fix.


That only leads to exponential code complexity as special purpose solutions get introduced.


> The bug has been in the wild for 8 years, so there are almost certainly customers who have VBA scripts that rely on that behavior

Most people weren't using 64 bit office until it became the default in 2019. Companies using any sort of legacy add-ins may still be using 32 bit office in 2021.

It's very unlikely that there's much VBA code relying on this specific broken behavior in 64 bit versions.


It does not show up in 32-bit mode. It does not show up on Macs. Therefore, it should probably be fixed.


There's a reason "bug for bug compatibility" is a thing, but this isn't it. I highly doubt anyone is relying on this, because it's completely stupid behavior.


Relying on completely insane behavior is a thing that surprisingly, lots of programs do...


https://xkcd.com/1172/

That noted, a broken IF statement does seem like a very serious compiler bug. And especially since the correct behavior occurs on Macs, I think a fix is necessary. The language should be consistent across all platforms at the very least.



> I highly doubt anyone is relying on this, because it's completely stupid behavior.

1. The person who posted the SO question said they rely on it. There are probably more who haven't discovered they're affected by this or who haven't spoken up yet.

2. An average VBA developer might be more likely to do something like this than you would be.


I just re-read the whole page, and, no, the SO poster is not relying on it. And, if anyone is relying on a bug that makes an if condition go the wrong way, that's so monumentally stupid, they deserve to have their stuff break.


From the original question:

> and also it blocks a migration to Office 64 here, because we can not get our code out


Wrong direction.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: