Skip to content

tor-socksproto API infelicities

  1. Callers must recapitulate much of the buffer management, including (i) the check that we aren't about to spin indefinitely reading 0 bytes (ii) the buffer data movement when we've consumed some data
  2. There's a magic constant 1024 (supposing @nickm accepts my suggestion in !2373 (merged)) which ought at least to be justified or something
  3. There is no typestate or anything to stop you calling things in the wrong order, eg into_reply out of sequence

I spotted this for the API of SocksClientHandshake (the client request state machine) while reviewing !2373 (merged) and looking at the arti code for calling it. Similar observations are likely to apply to the server side.