"Esme Povirk (she/they)" esme@codeweavers.com writes:
On Fri, Aug 27, 2021 at 2:29 PM Alexandre Julliard julliard@winehq.org wrote:
It doesn't look quite correct, you'd need to flush the buffer otherwise you'll potentially lose even more output.
The intent was to discard all output past the end of the buffer until the next line starts and __wine_dbg_output flushes it. If the buffer is full, it'll do a 0-size memcpy and overwrite the end. Is that what you mean?
If the caller sends multiple lines at once these will be discarded too, because of the strrchr('\n'). I'd argue that printing the data in multiple writes is better than discarding, but I still feel that this can be handled in the callers.
From a design perspective, I don't know if this is right, but I couldn't think of a better approach. Exposing the buffer size to callers seems not ideal to me. Is there an alternative I'm missing?
I'd suggest using debugstr_a/w like everywhere else. If you have to print an unbounded number of arguments, you can print them one per line.
Now that I think about it, I have no idea why I added those traces. Maybe I should just get rid of those.
I would still like to figure this out for the occasions when Mono produces really long trace outputs.
The best is to send them through debugstr_a/w, but you can also truncate or wrap them manually as seems appropriate. You don't need to know the exact buffer length, you can use say 600 chars (two debugstr's worth).