How can I get this 8 year old VBA 64-bit compiler bug fixed?

So here's the bug: In a 64-Bit VBA host (for example Access 365 64-bit or Excel 2016 64-bit) create a class module SomeClass:

' this needs to be here to trigger the bug: 
Private Sub Class_Terminate()
End Sub

and then some module Test:

Function ReturnFalse(o As Object) As Boolean
    ReturnFalse = False
End Function

Sub Test()
    Debug.Print ReturnFalse(New SomeClass)
    If ReturnFalse(New SomeClass) Then
        Debug.Print True
    Else
        Debug.Print False
    End If    
End Sub

Now, if you are using a 32-bit VBA host and run "Test" in the immediate window, the the expected result shows up:

False
False

However, if you are using a 64-bit VBA host, then this comes out:

False
True

Except, when you remove or rename the Class_Terminate() sub, in which case the correct output appears.

I've tracked the bug down to this minimal example. Apparently, the problem seems to be, that using a temporary object (new SomeClass here) breaks the evaluation of the IF condition somehow, making it appear that the value of the condition is True not matter what.

OK, that's a serious bug, because the 64 bit compiler is bonkers and all IF are in trouble.

All IF? what about WHILE?

While ReturnFalse(New SomeClass)
 Debug.Print "Oh no!"
Wend

Yes, WHILE is also in trouble, because this prints "Oh No!" in a loop.

That's a lot of trouble and I could reproduce it everywhere:

• Microsoft® Access® für Microsoft 365 MSO (16.0.14026.20294) 64-Bit
• Microsoft Access 2016 MSO (16.0.9029.2167) 64-Bit
• Microsoft Access 2013 (15.0.4420.1017) MSO (15.0.4420.1017) 64-Bit

..And also in Excel of course.

Summary: I could find this bug in all versions of Office I have, starting from 2013 and it is probably at least 8 years old.

Ok, did this bug affect other people before? Yes:

This post last year:

VBA takes wrong branch at If-statement - severe compiler bug?

This post in excel.uservoice.com (which apparently is Microsoft's user suggestion box or something) from October 2018:

https://excel.uservoice.com/forums/304921-excel-for-windows-desktop-application/suggestions/35735881-fix-inlined-member-calls-on-user-objects-on-64-bi

Allright, so let's file a bug report.

https://answers.microsoft.com/en-us/msoffice/forum/msoffice_excel-mso_mac-mso_mac2016/how-do-i-report-vba-bugs/bb4e5dea-9996-4232-9b5b-7dd57f76736c

If, after testing with others, the code fails and it really shouldn't, you can report the issue directly to Microsoft using the Smile button in Excel.

What?

https://answers.microsoft.com/en-us/msoffice/forum/msoffice_excel-mso_win10-mso_2016/excel-2016-vba-bug/b799dfc2-7cef-417d-8a41-96661a360c43

1. Open Excel > File > Feedback > Send a Frown
2. Through Uservoice - Click the following link to see the feedback of others and to provide feedback - https://excel.uservoice.com/

This is not a suggestion for a new icon color scheme. It is an 8 year old bug, which makes Access apps and Excel sheets with macros compute wrong answers (and also it blocks a migration to Office 64 here, because we can not get our code out).

Now here are my question:

• How can I get this bug fixed?
• Is someone with a reasonably impressive SLA or better connections here who would support my request?
• Is there a way to report VBA bugs directly? (This, because we currently suspect more bugs in the 64-bit VBA)
• I've made a new report in uservoice. Do you think it could be voted up? https://access.uservoice.com/forums/319956-access-desktop-application/suggestions/43660329-fix-this-64-bit-vba-compiler-bug-temporary-object

UPDATE: x-posted to

https://answers.microsoft.com/en-us/msoffice/forum/msoffice_excel-msoffice_custom-mso_2019/invalid-code-by-vba-64-bit-compiler/b91f984a-194c-4453-b8c5-02881afaf83b

UPDATE 2:

I had the chance to try the code on a Office 365 for Mac installation (where Win64 is defined as true) and the bug does not show up there. So it's a PC thing right now.

UPDATE 3:

Post made it to HN and The Register:

https://www.theregister.com/2021/08/19/64_bit_microsoft_vba_bug/ https://news.ycombinator.com/item?id=28188251

UPDATE 4:

Just checked today (2021-11-15) against Office 365 and the bug ist gone now! Looks like somebody payed attention. I can't figure out however, which of the gazillion cumulative updates I received this year did the trick and don't know yet, if the other Office versions are fixed too.

Solution 1:

Sub Test()
    Debug.Print ReturnFalse(New SomeClass)

    If ReturnFalse(New SomeClass) Then
        Debug.Print True
    Else
        Debug.Print False
    End If
    
    If True = ReturnFalse(New SomeClass) Then
        Debug.Print True
    Else
        Debug.Print False
    End If
End Sub

Returns

False
True
False

So If True = ReturnFalse(New SomeClass) Then fixes it

And for the loop this fixes it too

Do While True = ReturnFalse(New SomeClass)
    Debug.Print "Oh no!"
    Exit Do
Loop

Highly recommended to comment every usage of the workaround above so nobody removes that True = in the future (eg. because he develops in 32 bit and does not even run into the issue).

' Don't remove `True =` due to a compiler bug in x64 the condition would always be true. 
' See https://stackoverflow.com/questions/68034271/how-can-i-get-this-8-year-old-vba-64-bit-compiler-bug-fixed
If True = ReturnFalse(New SomeClass) Then

Even If ReturnFalse(New SomeClass) And False = True Then would be True with this bug.

Solution 2:

You can't do much more than what you have done already, unless you want to reach out to the tech devs directly/individually and risk getting on the annoying list, which would not necessarily help the chances of getting it actually fixed.

Uservoice is headed for the scrap heap but it does still get noticed and used by the product dev team, including right now in 2021.

VBA is not the current focus for programmability development, so I do not have a large amount of confidence that this will make it to the priority queue.