tyan0

I also cannot reproduce with `MSYS_NT-10.0-19045 HP-Z230 3.4.10--api-345.x86_64 2024-02-15 22:56 UTC x86_64 Msys` and `MSYS_NT-10.0-19045 HP-Z230 3.4.10.x86_64 2024-02-10 08:39 UTC x86_64 Msys`.

With this test case, `repr.exe` is a native win32 binary (not cygwin/msys2 one), and `python3` is a cygwin/msys2 binary. Right?

Ah, I could reproduce when repr.exe is built with mingw UCRT compiler. If this is compiled with `/mingw64/bin/gcc ` the issue does not occur.

I found the cause. Currently, select() call for write-side of a pipe possibly hangs for non-cygwin reader. However, it is difficult to explain why. Please refer to https://github.com/mirror/newlib-cygwin/blob/master/winsup/cygwin/select.cc#L614 for detail....

I cannot say that there is never a risk of regression, however, as far as I tested (with many of my video archives and the test cases of which recently...

Fixed a bug reported in https://github.com/cisco/openh264/pull/3772

I'm very sorry for extremely long delay. Finally, I could reproduce the problems with the testcases: clusterfuzz-testcase-minimized-decoder_fuzzer-4680815741042688 (#3745) clusterfuzz-testcase-minimized-decoder_fuzzer-6315387293597696 (#3746) I'll look into these problems.

As for #3745, the code in decoder_core.cpp expects that the arithmetic overflow in int32_t results into wrapped-around result. Oss-fuzz complains about that. C/C++ standard states the overflowed result is undefined...

No, it is not. Current code works as expected on the most systems (where two's complement is used for negative value) with gcc. However, C++ standard inhibit expecting the certain...

Sorry, I noticed above patch causes test failure. I'd like to propose alternative fix below. New patch enables the function WelsReorderRefList2() which was introduced by the commit 1b8caef6ccc7, and fixes...