debug logs format
i integrated (really easily, congratulation for this lib !) PolarSSL in my C++ project. This project is using a logging system where, among others, files names, line numbers are sent to an appender that can just print the log with a layout or add it in a database, or what ever the final user want to code. (something similar to log4j)
in PolarSSL, the file name and line number is used to format a "final" log entry that is then passed to the debug call back registered with ssl_set_dbg(...)
would it be possible to add a new ssl_set_dbg method allowing to pass a callback such as : void debugCallback(void * parameter, int level, const char * messageWithoutFileAndLine, const char * file, int line);
so that the raw , undecorated message would passed and the file name and line number could be retrieved, without having to process the formatted message to extract this infomation.
Thank you for your consideration
Thanks for the compliments.
I understand your described scenario. If we would add such a feature it would be a compile time flag.
I don't see any big issues beforehand, might happen later. It has been added to our internal TODO list for 1.3.1 (Not the upcoming 1.3.0 release)
That would be fine for me.
Hi paul, I upgraded to 1.3.1 so i checked for this as u said it may be implemented in 1.3.1. but i can't find such compile option. for a future version maybe ?
You are right. Sorry about not updating this thread.
When implementing a define for the separate 'file-line-data'-format we ran into issues with the more complex log messages. Specifically the ones that try to do multi-line log messages, because they do multiple calls (as if it is a stream) with data and newlines in consecutive calls. If we just replace the debug log function with a new variant (with line and file separate) this would result in non-pretty logs
FILE:LINE:0x54 FILE:LINE:0x55 FILE:LINE:\n
Concatenating inside the debug functions is what we want to avoid if possible.
We did not yet have time to dive in further to create a pretty patch without complicating the current functions too much. It IS on our list of things to do.
OK, thanks for feedback !