[HN Gopher] How can I get this 8 year old VBA 64-bit compiler bu...
       ___________________________________________________________________
        
       How can I get this 8 year old VBA 64-bit compiler bug fixed?
        
       Author : segfaultbuserr
       Score  : 135 points
       Date   : 2021-08-15 12:33 UTC (10 hours ago)
        
 (HTM) web link (stackoverflow.com)
 (TXT) w3m dump (stackoverflow.com)
        
       | sk5t wrote:
       | (Tangential) Got to scratch my head at this "authoritatively
       | voiced" bit of advice in the SO thread:
       | 
       | > Testing the result of a constructor in any language is probably
       | a dodgy practice. It's an object or it's a 'null'.
       | 
       | Ah, if there's an OO language anywhere that can return null from
       | a constructor invocation, I have yet to see it.
        
         | kevingadd wrote:
         | 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...
        
         | thom wrote:
         | Dunno if this counts but it's not unheard of to return nil from
         | init methods in Objective-C.
        
           | hugey010 wrote:
           | Yep, afaik if allocation of memory for the object fails it's
           | canonical to immediately return nil.
        
         | pwdisswordfish8 wrote:
         | C++ with new(std::nothrow)?
        
           | rzzzt wrote:
           | Or maybe if a new_handler is installed, which returns.
        
         | benibela wrote:
         | Delphi/Pascal has 2-layered constructors.
         | 
         | 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
        
       | lloydatkinson wrote:
       | 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.
        
       | phendrenad2 wrote:
       | 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.
        
       | daniel-thompson wrote:
       | 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.
        
         | adrianmonk wrote:
         | 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.
        
         | resoluteteeth wrote:
         | > 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.
        
         | actually_a_dog wrote:
         | 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.
        
           | my123 wrote:
           | Relying on completely insane behavior is a thing that
           | surprisingly, lots of programs do...
        
           | yegle wrote:
           | https://www.hyrumslaw.com/
        
           | daniel-thompson wrote:
           | > 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.
        
             | actually_a_dog wrote:
             | 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.
        
               | daniel-thompson wrote:
               | From the original question:
               | 
               | > and also it blocks a migration to Office 64 here,
               | because we can not get our code out
        
               | malf wrote:
               | Wrong direction.
        
           | magpi3 wrote:
           | 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.
        
         | petters wrote:
         | It does not show up in 32-bit mode. It does not show up on
         | Macs. Therefore, it should probably be fixed.
        
       | larrybud wrote:
       | Shrug... so there's an 8 year old VBA bug? I'm sure there are old
       | Windows/IOS/Android/MacOS/Ubuntu bugs that similarly have not
       | been fixed.
       | 
       | Here's a 6 year old IOS bug that affects my old videos that's
       | still around, despite being reported when it first cropped up:
       | https://discussions.apple.com/thread/7226531
       | 
       | 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.
        
         | magpi3 wrote:
         | 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.
        
         | aluminussoma wrote:
         | 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.
        
       | CalChris wrote:
       | Use it to demonstrate an exploit.
        
       | mmastrac wrote:
       | Easiest way to get it fixed is to make it exploitable somehow.
       | Could be an interesting VBA sandbox escape if the stack frames
       | are incorrect
        
         | exmsrcer wrote:
         | This wouldn't work to force a fix, as the security boundary is
         | prior to any VBA code being executed, with the macro security
         | warnings and suchlike.
        
       | azalemeth wrote:
       | 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...
        
         | bcrl wrote:
         | 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...
        
         | syshum wrote:
         | Commercial Support is more CYA for the people implementing
         | technology, not a realistic way to get actual support
         | 
         | It is way to shift blame, and responsibility
        
           | jeremyjh wrote:
           | 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.
        
         | mhh__ wrote:
         | If you have an open source project and you really need it,
         | don't pay for support (by default at least) - pay someone to
         | work on it, for you.
        
         | na85 wrote:
         | >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...
        
           | [deleted]
        
       | [deleted]
        
       ___________________________________________________________________
       (page generated 2021-08-15 23:02 UTC)