A common complaint about FOSS development or requirements is that you get what you pay for in terms of support. It's good to see that commercial offerings are not much better!
MS office is arguably the biggest piece of commercial software on the planet, and as this neatly shows, you still get bugger all in terms of support. I really dislike the embedded VBA "enterprise" Windows/Office world -- it either works, or you can hack it to work (CF the SO answers) or, if neither of those things are true, you are SOL...
>I really dislike the embedded VBA "enterprise" Windows/Office world -- it either works, or you can hack it to work (CF the SO answers) or, if neither of those things are true, you are SOL...
Hah, I work in aerospace so I deal with a lot of security BS, and once had to address the fact that some IT techs were tracking the maintenance status of some TEMPEST-compliant security gear with a hacked-together VBA "application" that ran in excel over SMB shares.
The password for the master database was (heavily) obfuscated but otherwise just hidden in plaintext in the tech-facing side of the application that ended up remaining installed on unprivileged machines that got loaned out to contractors, etc.
The CISO agreeed that if the public has access to the status and configuration for your classified processing machines then that's a fairly concerning breach but was confused because the head of IT had told him it was all end-to-end encrypted...
I recently learned that it's virtually impossible to get Intuit to acknowledge bugs in QuickBooks Online. And if they do acknowledge the bug, they close your ticket and won't provide any further updates (like if the bug will ever get fixed). At least with open source packages I can fix the damned thing myself if the vendor won't help out. If only the right to repair was actually enshrined in consumer protection laws...
It is often used for that purpose, but I've opened cases with Microsoft premier support that led to a patch. Premier support is expensive but worthwhile in my experience.
There is a virtual class method to allocate memory and a so called constructor that initializes fields that should be zero.
The user of a class, only calls the constructor. The constructor then calls the memory-allocation method implicitly (you can see the call with a disassembler, but not in the Pascal code).
Anyways, you can override the memory-allocation method for each class. E.g. a useful case would be to build an arena allocator just for that class. But you can also override it, so that calling the class constructor returns a null
C# constructors technically don't return anything (afaik), the object is allocated and then the constructor is invoked on it. So it's theoretically possible for your compiled code to produce a null as the result of a 'new' expression. I think this wouldn't be spec compliant though, since the two scenarios where this would make sense (OOM and exception thrown during alloc or ctor) should just throw and unwind before you can see observe the null or uninitialized instance.
FWIW, it's also possible to enter an instance method with a null 'this' under certain circumstances (normally there would be a null reference check before entering the method body, but I've run into cases where there wasn't)
Contrived scenario: You AOT-compile your code in a 'no exceptions' mode, so the generated code assumes that malloc can't throw, etc. In that case if a failure happens during the 'new' process the only reasonable return values are either null or an instance with garbage data in it. As a compiler author, out of the two I'd probably pick null. This isn't as far-fetched as it sounds since right now exception handling in WebAssembly is a nightmare.
Actually, I wonder if an exception filter could observe the null before the unwind happens...
Some interesting points there about User voice being head d for the scrap heap (as if it was ever really given much attention from teams at MS anyway) and that VBA isn’t the focus for programmatic extension anymore.
Seems that the closest is the recently announced Python for Excel only (and even then I remember it seemed to be online only or something equally crippled) or PowerApps which I guess might actually be a reasonable but still online only alternative.
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.
> 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.
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.
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.
This is the kind of bug that open-source people love to work on. But, are people experiencing it in the wild? If so, Microsoft will fix it. If not, enjoy the other things Microsoft spent their time on otherwise and forget about it.
If you use collection classes in vba you can run into this bug pretty quickly. Last year I deployed an Excel add-in to a client that enabled them to run Snowflake queries concurrently from vba and this line:
If queries.FilterHasError().Count > 0 Then
was being evaluated as true even when the count was zero.
I had developed the add-in using 32-bit Excel. This was an extremely confounding troubleshooting experience. Eventually Google & Stackoverflow rescued me from believing I was going crazy.
Not sure why the article is HN newsworthy.... is the implication that because this is a "developer tooling" bug, it's somehow more important, or more likely to be fixed, than any other bug? IMHO, that's not a valid expectation.
I think it is more important because it is a broken IF statement in a language. If IF statements were broken in a popular open source language, I am sure it would be discussed thoroughly here and fixed ASAP.
The hideous workaround is why it is here. Super interesting to see someone else carve an unintuitive path forward against seemingly unmovable obstacles. Very much a hacker mentality.
MS office is arguably the biggest piece of commercial software on the planet, and as this neatly shows, you still get bugger all in terms of support. I really dislike the embedded VBA "enterprise" Windows/Office world -- it either works, or you can hack it to work (CF the SO answers) or, if neither of those things are true, you are SOL...