Hi armin,
> This would print wrong-ish timestamps that couldn't really be used for profiling (I mean, it could; you just have to know which timestamp belongs to which message). I would suggest to
> rather store a flag after reading `\n` and attach the timestamp to the following message.
I am also following this approach for printing timestamp and FT_COMPONENT.
Actually dlg uses a flag `dlg_features` in which different features like `dlg_output_timestamp`(for timestamps) and `dlg_output_tags`(for FT_COMPONENTS) are summed up using binary OR operator.
For the first log message, these flags are kept ON so that timestamp and FT_COMPONENT values are printed, and for the next coming log messages the following logic is used:
If the current log message contains a `\n` in it then the flags will be toggled ON for the next coming log message assuming that it is end of a log message,
and if the current log message doesn't contain `\n` then these flags are toggled OFF for the next coming log message assuming that it is in continuation of current log message.
> Also, I would believe that `fmt[strlen(fmt) - 1] == '\n'` is rather fast, esp. given that this is followed by an IO operation. To be tested though :)
OK
> Writing this lead me to look for multi-linebreak traces (e.g. src/pcf/pfcread.c:504) -- should that have one timestamp for the entire statement or one timestamp per line?
With the above logic for these types of logs, there will be one timestamp per line...
Thanks,
Priyesh