This makes it use OUR timestamp, so timestamps in logs are properly
sequential. The originial timestamp is saved in "original_timestamp".
Finally, we (over)write "log_source" with the remote server name.
snomasks, opers, global (remote), ..
For disk logs we currently ignore the sources and log everything.
NOTE: REHASH is untested and will memory leak for sure.
This means we now have $client.user.username but the expansion system
does not allow items more than 2 deep atm (only $client.something
but not $client.something.other). Will fix later. (TODO)
In the meantime the connection notice will look weird :D
Also rename them to describe better what they do.
ConfigFile:
cf_filename -> filename
cf_next -> next
cf_entries -> items
ConfigEntry:
ce_fileptr -> file
ce_varlinenum -> line_number
ce_fileposstart -> file_position_start
ce_fileposend -> file_position_end
ce_sectlinenum -> section_linenumber
ce_varname -> name
ce_vardata -> value
ce_cond -> conditional_config
ce_entries -> items
ce_next -> next
ce_prevlevel -> parent
Also add doxygen docs for both structs.
Note that without such a block nothing will be sent to ircops at all
(anything that comes from unreal_log anyway).
In a later commit either a snomasks.default.conf will be added and/or
an internal default mapping.
This also moves the recursion trap to earlier in the logging code,
which has the side effect that debug traffic regarding snomasks is
no longer logged.
when any of these are wrong. Obviously this should probably be changed to
only do it in DEBUGMODE in a final stable release :D
We also crash if 'msg' contains a percent sign ('%'). This is to avoid
mistakes where someone uses eg '%s' in there, which is not supported.
Unfortunately it also prevents stuff like '100%' so this should probably
be removed too at some point.
The former is an integer and may not always be available (eg: very early
before the user is connected). The latter is an array.
TODO: opt-in/out of all these expansions as they come at a performance penalty
a wrapper that will return a 'null' JSON object for null strings and
otherwise a string object for non-NULL. It seems by default this is
not the case which is a bit annoying. Maybe we should re-wrap all
code to use this. We'll see.
The problem is when this is not done, then a $variable won't be
expanded and would show up like literally "$variable" as if the
variable was never passed on.
being NULL. This is a vararg argument and it causes a leak when
running in debug mode because we add some magic source file,
source line number and function.
Note to self: don't put NULL there :D
Bram Matthys