mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-10-01 14:58:14 +00:00
Henrik Rydgård
bc095c5e31
Found reviewing the commits before this one. On Windows a short write marked the request complete and then queued another read regardless, which is worse than it sounds: the caller is free to close a response the moment it sees complete, so WinHTTP carried on writing into memory that was being freed. It also meant cancelling didn't actually stop anything there. Stop at that point, and ignore anything raised after the request is complete. The Apple callbacks do the same check, so the cancellation we ask for after a failed write doesn't overwrite the error that caused it. naettMake only asserted that its request was non-NULL, and the request constructors do return NULL when a platform can't set one up - an unparseable URL is enough on Windows. Asserts are compiled out in release, so that was a null dereference. It returns NULL now, and HTTPSRequest checks for it and fails the request instead of handing it on. Also: a request cancelled between construction and Start() didn't carry that into the sink, and -1000 - our own cancellation code, not naett's - was logging "Unhandled naett error" on a perfectly normal cancel.