Files
ppsspp/Common/Net
Henrik Rydgård 1041c976c6 http: Say what the sink's ownership actually is
unique_ptr, not shared_ptr. Nothing ever shares it: naett holds a raw pointer
and takes no part in the counting, and the abandonment path hands the sink over
and lets go in the same breath. What's really going on is a single owner that
moves, which is what unique_ptr says and shared_ptr left you to work out from
reading all the uses.

naett never frees the pointer it's given for the writer - it only reads
bodyWriterData and hands it back to the callback - so deleting the sink is
ours to do. The things naett does allocate, the request and response, stay raw
pointers with explicit naettFree/naettClose.

The length field was just buffer.size() written down twice.
2026-09-05 13:57:31 -06:00
..
2026-08-11 04:12:46 +03:00
2026-08-11 04:12:46 +03:00
2026-09-02 18:15:17 +02:00
2023-12-29 11:44:22 +01:00
2025-08-15 18:08:41 +02:00
2026-04-28 22:17:24 +02:00