/post/2 Back

New backend logging system

Posted 2026-08-24 03:15:08
New verbose outputs, Seeing as you smucks only viewing the frontend -- don't get to see the backend I thought I should make a statement. In the backend the entire verbose/logging system has been re-done which has fixed a few large issues in the functionality of the backend. A few weeks ago, I was using the TinyCSocket library for socketing. I used TinyCSocket because at the time it was what I was most experienced in, TinyCSocket was used in a prior project of mine; trcs. TinyCSocket is great, its very simple to use and I think its great for learning the socket basics or for prototyping. I've finished depreicating TinyCSocket and hence removed it from the codebase completly, In its place I've used the built-in POSIX socket and net library headers. This dident take too long but one thing that broke was the get_client_ip function which logs the IP address of the connected client on the hosts stdout. Alot of other architechtual issues where based in the logging system. The way the webserver is setup is the main loop awaits connections, these connections are offloaded onto a seperate thread where the clients headers are read, then the method and endpoint is filtered from the headers and passed into the page routing function which decides what page the client is trying to go to (based on the endpoint) and then serveing the content for said page. The old method for logging was done in the header() macro/function which is called to set the return code and reason to the client (such as 200 OK or 404 Not Found). This was done so that logs can contain the code and response. In hindsight this was very stupid as it meant that every page function was REQUIRED to have a parameter to pass in the endpoint and method that way the header function/macro could log that too. This was a very linear approach which has caused a daisy-chain of parameter passing.

This has now been solved by making pages return the header code that they returned,then having that code returned back from the routing function to the initial thread function where it is then logged. This method is great as now function pages do not need to take in parameters for the method and endpoint. This also cleans up the code in the pages header.

The next step was verbose outputs. I need a way to log outputs of functions that need debugging but without it clouding the clear water that is the regular outputs. I previously had a error() macro that would act as printf for the stderr but other then that debugging was done by creating new print statements in areas that needed them before removeing them after use. I wanted to change this. I wrote a small macro that takes a output file descriptor, a verbose level and the regular format and arguments that printf would take. Along with this there is a global variable that determines what calls are actually printed. The available modes are DEBUG, BASIC and NONE, if the global log level is set to DEBUG then ALL verbose statements will be shown, if its set to NONE then none will be shown. I'm getting bored of writing if you could not tell so if you need/want any more information then please read src/deps.h.

Thanks