memcpy(frame + 12, client->remote.host, client->remote.host_len);
It's 2015. One should not be hand-coding string manipulation at the pointer level. memcpy(frame + 12, client->remote.host, client->remote.host_len);
It's 2015. One should not be hand-coding string manipulation at the pointer level.Defensive programming like that is a very good idea especially for something network facing.
If you're sure it's always at most 46 bytes, make it 48 bytes and specify "#define BUD_MAX_HOST_IP_LEN (48)".
Very secure and compiler will probably replace those memcpys with a few SSE [1] instructions, because 48 is a multiply of 16.
Copying 48 bytes is always much faster than copying 1 byte with a dynamic length argument for memcpy.
[1]: Like 6x MOVDQU instructions. Probably interleaved with the rest of the code to hide latency.
If bud was my own pet project, I'd write it in Golang, which is great for networking code. The software I've written so far in Golang has been rock solid, with practically zero defects, in addition to being very understandable and readable code for other people. I wish I could say same of C/C++...
Or maybe in Rust to get a better hang of it. I think Rust will eventually capture a lot of C/C++'s "market share". It should be feasible to write firmware, operating systems and device drivers in Rust.
True, although that was building a binary message, not exactly a string.
"frame" should have probably been a (packed) struct instead of "unsigned char frame[256];".