Possibly add SEH wrapping through linked libs about win32metadata

[kennykerr]

I can transfer this issue to the Win32 metadata repo for discussion.

[tim-weis]

SEH is a system service that requires compiler (and language/language runtime) support. This should be filed against rustc for resolution.

@riverar This goes beyond (or underneath) API calls. MapViewOfFile(), for example, returns the equivalent of a region of memory. Dereferencing a pointer anywhere inside the reported valid range of the mapping can raise an SEH exception (e.g. when the file object backing the mapping becomes inaccessible).

The core issue here cannot be solved by annotating APIs alone, and a cursory search didn't uncover any hope for a resolution over the current workaround.

[kennykerr]

Adding some folks who may have some comments on SEH in Rust as well as some who are currently using a mix of Rust and C to make it work. @sivadeilra @dpaoliello @zadjii-msft

[kennykerr]

As for me, we don't have metadata at the moment that calls out which functions use SEH so I don't think this is very actionable at the moment.

https://kennykerr.ca/rust-getting-started/how-are-crates-built.html

[RivenSkaye]

I'm somewhat surprised that something like that isn't tracked through the metadata yet; I'd assume the information is relevant internally and the win32 C/C++ docs do make mention of using the __try handlers in some places. Should I open an issue there to ask for including it in the metadata output?

[riverar]

Do you have some example APIs in mind?

[RivenSkaye]

Not quite sure which end of the issue you'd want example API's for; the existing APIs where __try/__except are currently used, examples for the Rust end of things, or examples for the metadata definitions?

My initial request was aimed mostly at situations where the function call itself can reasonably cause these to be thrown, e.g. accessing networked locations can cause EXCEPTION_IN_PAGE_ERROR and in some situations, or for getting a generic function that allows users to register their own filter and handler functions; that said some of the SDK functions can also cause some of the recoverable ones to be thrown. The simple wrapper could look like

// Code may not be perfect, I'm not experienced in passing around functions in C++
void TryUserFn(DWORD[] handles, *void callable, *void handler, *void outvar) {
    __try {
        *outvar = callable();
    }
    __except(arr_contains(handles, GetExceptionCode())) {
        handler();
        *outvar = NULL;
    }
    return 0;
}

as a bare method of allowing people to attempt recovery or warning users

[riverar]

Not aware of any APIs using SEH so closing this for now. Feel free to keep the discussion going and let one of us know if we need to re-open this. Thanks!