> However, is it common for production C code to have a single file with 5,300+ lines?
It's definitely not uncommon, but yes, that file is on the long side. However, it is rather clean and well-organized.
It may be due to the poor module system (header files) of C where you end up making files slightly longer than ideal because splitting into two files means also adding some header files and thus adding to the maintenance burden.
When writing C code, I usually strive to put a whole "module" in a single file, so that no "private" interfaces have to be put in header files. Everything that needs to be exposed in order to test a module goes in the public interface.
It's a tradeoff and C being C doesn't help (and C++ wouldn't really help here IMO), but I see nothing wrong with the file you picked. It's a bit long but it looks well done to my C programmer eyes.
Right off the bat, I see multiple instances of str* functions where strn* functions should be used. I'm also wondering about this variable "server" which seems to have an unknown definition. There are lots of gotos, and many other deferred high-quality conventions, such as explicit parenthesis in comparisons, re-ordered fields in comparisons, chains of else ifs, where a switch would be preferable.
I also see lots of prototypes (all?!) defined at the top of the file instead of in a header file. They could be made static.
Also, the generic type "int" isn't a good idea because it can change, it helps avoid porting problems to specify the size (int32_t, uint64_t, etc.)
And the memcpy()'s should be changed to memcpy_s().
On the bright side, the comments are quite good and plentiful. Refreshing!
It's definitely not uncommon, but yes, that file is on the long side. However, it is rather clean and well-organized.
It may be due to the poor module system (header files) of C where you end up making files slightly longer than ideal because splitting into two files means also adding some header files and thus adding to the maintenance burden.
When writing C code, I usually strive to put a whole "module" in a single file, so that no "private" interfaces have to be put in header files. Everything that needs to be exposed in order to test a module goes in the public interface.
It's a tradeoff and C being C doesn't help (and C++ wouldn't really help here IMO), but I see nothing wrong with the file you picked. It's a bit long but it looks well done to my C programmer eyes.