SOCKS5 responds with no BND.ADDR nor BND.PORT?

Although this looks like a bug, some developers argue how it complies perfectly with the RFC.

I wrote a simple C++ program on Linux which connects to a HTTP web-page and reads its contents over Tor. I start a tor service using this command:

tor --ignore-missing-torrc -f / --SocksPort auto --DataDirectory $HOME/tren/tor_0

$HOME/tren is just a directory I mount as tmpfs (btw, the same happens even if I only run tor). Tor connects successfully and I can use its socket. Now my program negotiates with the port like this:

I send {5,1,0}
SOCKS5 sends {5,0}
I send {5,1,0,3,17,www.icanhazip.com,0,80}
SOCKS5 sends {5,0,0,1,0,0,0,0,0,0}

This domain name address is written byte by byte, without null termiation. Why is my SOCKS5 responding with 0 address? If I connect to the web-site using it's IPv4 that I resolve locally, the same happens. I try requesting HTTP page and it responds properly.
I am using Arch and I have installed it's official tor package.

EDIT: I deleted my code as it was incomplete and far from 'minimal'

Solution

Your SOCKS5 request is perfectly fine, and the proxy is replying back that it successfully connected to www.icanhazip.com:80, so just start exchanging your HTTP data as needed over your existing connection to the proxy.

The proxy's reply is simply telling you that it bound itself to 0.0.0.0:0 (or maybe it is choosing not to tell you the actual IP/port it is bound to) when it connected to www.icanhazip.com:80:

                       BND.ADDR/BND.PORT
                              |
                              \/
+--------+          +-------+          +--------+
| Client | x <-> p1 | Proxy | p2 <-> y | Target |
+--------+          +-------+          +--------+
                        ^
                        |       +-----+
                        +-----> | DNS |
                                +-----+

The zeros you are referring to are in the BND.ADDR/BND.PORT fields of the proxy's reply. Those fields represent p2 above - the outbound IP/Port used by the proxy to connect to the target server after it resolved the hostname that your client requested. It sounds like you are expecting those fields to contain the inbound IP/port for the target server at y instead, which is not the case.

You don't need to know the target's IP/Port in order to use the connection. You have a fully functional tunnel between you and the target via the proxy, just use the connection as-is once the tunnel is established. You just won't be able to know the target's IP/Port. You can't get that info from the proxy. The only way to get it is to either resolve the hostname yourself (which defeats the purpose of asking the proxy to resolve it for you), or else ask the target itself (if it has a script for that purpose).