#23878: Attempt rewriting buffers.c in Rust -------------------------------------------------+------------------------- Reporter: isis | Owner: (none) Type: enhancement | Status: new Priority: Medium | Milestone: Tor: | unspecified Component: Core Tor/Tor | Version: Severity: Normal | Resolution: Keywords: rust-pilot, rust, datatypes, | Actual Points: 034-triage-20180328, 034-removed-20180328 | Parent ID: | Points: 3 Reviewer: | Sponsor: | Sponsor8-can -------------------------------------------------+-------------------------
Comment (by cypherpunks): Since [https://gitweb.torproject.org/tor.git/commit/?id=d8b34e0886c9fd08fb51e0de4fadca7da82056ff d8b34e0886c9fd08fb51e0de4fadca7da82056ff], buffers.c has been split and refactored four ways now, so there are three callers in the C code that still dig into the implementation detail guts of `buf_t` in search of raw pointers, presumably with the benefit of zero-copy performance. Could `compress_buf.c`, `buffers_net.c`, and `buffers_tls.c` just switch to using the single-copy public API, or should a new zero-copy API be added that the Rust version can implement too? It could be something that synchronously invokes a callback exposing a raw pointer, so that the return value tells `buf_t` how many bytes were written/read, and the callback serves as a clear sign to users the pointer is not guaranteed to remain valid past the end of that function. {{{ typedef size_t (*buf_read_cb)(const char *string, size_t string_len, void *data); typedef size_t (*buf_write_cb)(char *string, size_t string_len, void *data); void buf_read_call(buf_t *buf, buf_read_cb *cb, void *data); void buf_write_call(buf_t *buf, buf_write_cb *cb, void *data); }}} -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23878#comment:8> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs