C, with [[clang::musttail]]

It will happen even without swap. Code pages will get evicted and everything will slow down to a crawl. I have magic SysRq enabled so I can invoke OOM killer from keyboard if that happens.

I would want that too. It's possible in MySQL: https://dev.mysql.com/doc/refman/8.4/en/create-index.html#cr...

mysql_real_escape_string is only deprecated because there is mysqli_real_escape_string. I always wondered why it's "real"...like is there "fake" version of it?

Yes.

https://www.php.net/manual/en/function.mysql-escape-string.p...

https://stackoverflow.com/questions/3665572/mysql-escape-str...

One hardly even tries to do the thing it says on the tin, the other one at least tries to be the real thing. None of them worked very well, however.

I'm not sure if second argument is correct either. When assigning through *mut pointer, Drop will be called for previous value, but there's no guarantee that this value is zero-initialized. (according to https://devblogs.microsoft.com/oldnewthing/20091231-00/?p=15... callee is required to initialize all output arguments, which implies that caller is not required to). It should be represented as &mut std::mem::MaybeUninit<BSTR>

I think you're right. My mistake. Maybe the best option is `&mut windows_sys::core::BSTR` (using the unsafe BSTR type I mentioned), since that way the same BSTR type can be used for the two arguments. Or `*mut BSTR`, since windows-rs itself seems to prefer raw pointers for whatever reason, though I found crates using windows-rs that seem to successfully use references.

I am slightly suspicious that Raymond Chen might have been confused. The link in that post has the text "forget to set the output pointer to NULL", but in the linked post (the original link is broken but it's at [1]), the implementation actually set the output pointer to a garbage value rather than leaving it untouched. I wonder what the marshalling implementation actually looks like…

But at any rate, treating the out pointer as uninitialized is definitely the safe option. I'm not 100% sure whether it can legitimately point to non-null, but if it does point to non-null, then that value is definitely garbage rather than something that needs freeing.

[1] https://devblogs.microsoft.com/oldnewthing/20091007-00/?p=16...

>I think you're right. My mistake.

I didn't disagree with you, I just wanted to point another issue.

Actually *mut BSTR (owned) is also acceptable, iff you remember to use std::ptr::write instead of normal assignment.

> I'm not 100% sure whether it can legitimately point to non-null

Note that in none of the examples on this and other posts (like https://devblogs.microsoft.com/oldnewthing/20040326-00/?p=40...) output value is initialized, so it will be whatever is lying on the stack.

These are all great points, and I will update the blog post to reflect them in the morning.

I believe this approach can work while retaining the most apparently-idiomatic mapping. What do you guys think?

impl IRibbonExtensibility_Impl for Addin_Impl {

    unsafe fn GetCustomUI(&self, _ribbon_id: BSTR, out: *mut BSTR) -> HRESULT {

        log("GetCustomUI called()");

        std::mem::forget(_ribbon_id);

        if out.is_null() {

            return windows::Win32::Foundation::E_POINTER;
        }

        unsafe {

            std::ptr::write(out, BSTR::from(RIBBON_XML));
        }

        S_OK
    }

}

Looks fine to me, if you're avoiding wrappers like ManuallyDrop/MaybeUninit.

Actually the `windows-rs` team weighed in:

impl IRibbonExtensibility_Impl for Addin_Impl {

    unsafe fn GetCustomUI(

        &self,

        _ribbon_id: windows::core::Ref<BSTR>,

        out: windows::core::OutRef<BSTR>,

    ) -> HRESULT {

        log("GetCustomUI called()");

        if out.is_null() || out.write(BSTR::from(RIBBON_XML)).is_err() {

            return E_POINTER;

        };

        S_OK

    }

}

https://github.com/microsoft/windows-rs/issues/3832

Thanks for pushing on the issue! I've updated the blog post for GetCustomUI.

>In fact, despite many minutes of bona fide web searching, I was unable to locate the C++ signature for IRibbonExtensibility.

Probably because the COM "intended" way is to generate them from type library. Type library for these interfaces is embedded in Office MSO.DLL. You can use oleview.exe from Windows SDK to convert them to IDL syntax. This yields such signature:

    HRESULT GetCustomUI(
                            [in] BSTR RibbonID, 
                            [out, retval] BSTR* RibbonXml);

And then you can use MIDL tool to generate C headers:

    DECLSPEC_XFGVIRT(IRibbonExtensibility, GetCustomUI)
            /* [helpcontext][id] */ HRESULT ( STDMETHODCALLTYPE *GetCustomUI )( 
                IRibbonExtensibility * This,
                /* [in] */ BSTR RibbonID,
                /* [retval][out] */ BSTR *RibbonXml);

https://learn.microsoft.com/en-us/windows/win32/com/how-deve...

I actually stumbled upon that toward the end of the exercise, but couldn't figure out where `oleview.exe` landed after I installed the SDK. I only spent a couple of minutes, and at that point I was only looking to confirm what I already knew, but this will be the approach if/when we extend it.

Story of how Intel-derived proposal was standardized as IEEE754: https://people.eecs.berkeley.edu/~wkahan/ieee754status/754st...

SPICE can do that with 'gshunt' option.

I played Rift Apart from HDD and apart from extra loading time during looped animations it was fine. On the other hand Indiana Jones Great Circle was barely playable with popping-in textures and models everywhere.

Unless you are playing Quake through Iridium.