talchas

It would definitely be a breaking change to the language, though not one that is likely to come up fully inside of rust: ```rust #[no_mangle] extern "C" fn foo(x: c_int)...

Yes, my point is that this is absolutely a breaking change and what it buys is "able to implement an existing API that is way more C++-centric than it should...

While related, that still isn't `i32`-vs-`c_int`, just issues with types that are a little more special in rust in general.

Try v10, it looks like the most likely cause should be fixed now.

Yeah, there is no correct value for the alpha components in BlendFuncSeparate with rendering arbitrary inputs to a temporary texture like this - you want `alpha = 1 - (1-dstalpha)...

Is it a good idea in the first place to have these combinators which cause conflicts with `futures::stream::StreamExt` but don't replace `futures` entirely? `timeout` and `throttle` obviously are tokio-specific, and...

No, it's **absolutely** a problem in practice. The load of next is outside of the llsc region, so it doesn't matter about the "might" in the spec. A preemption before...

This is still a problem, and makes clone completely broken (rather than the expected horribly unsafe because it's clone). FnBox has been fixed for a while, though it would be...

I'd go with ```rust pub fn clone c_int + Send + 'static>( cb: F, stack: *mut [u8], flags: CloneFlags, signal: Option, ) -> Result { extern "C" fn callback c_int...

Yeah, I didn't do &'static because it would need unsafe anyways, and didn't do Box because of the freeing issues, and statically allocating a buffer is maybe useful sometimes. You...