development branch regression: empty lines

[tomasbrod]

72efb5d often produces double new-line where there was previously just one, thus spacing the log vertically.

[tomasbrod]

Some LogPrintf calls have newline character and some do not in the code. Furthermore a overload of the function with format parameters does append it's own newline while the one without does not.

Should the newline be auto-appended on all calls?
-> remove the newline from many invocations of LogPrintf
Or should the newline not be appended?
-> add newline to many invocations
Or should the newline be only appended to call without a newline?

In other words do we want to allow LogPrint without a newline, so that the next log prints to the same line?

[iFoggz]

It was mentioned to me before that newlines are not needed with LogPrintf()

is this not correct?

If not I think LogPrintf should be doing the new line based on system it is running on. like windows \r\n, nix \n, etc.

We have some old debug messages that compact on single lines due to no new line and we have some messages with \r\n and others \n. I think it would be "optimal" if the LogPrintf() did the new line itself based on system it was running on. It would save a lot of hassle and make thing more clean imo.

Just my opinion.

also the commit 72efb5d you mention is about the locking system, there are no LogPrintf() in those commits?

[tomasbrod]

The commit, i mean as a revision. Not necessary changes introduced in that commit.

Windows console does understand \n, or at least there is something in libc that makes \n work on both systems. That is not a problem.

Problem is that BOTH LogPrintf adds a newline and the message contains a newline, resulting in double newlines. I want to discuss how to solve this situation. Clearly one of the newlines has to be removed, but which?