[PATCH] ntdll: Truncate and ellipsize debug output if it's too long.

Alexandre Julliard julliard at winehq.org
Tue Aug 31 05:03:13 CDT 2021


"Esme Povirk (she/they)" <esme at codeweavers.com> writes:

> On Fri, Aug 27, 2021 at 2:29 PM Alexandre Julliard <julliard at 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).

-- 
Alexandre Julliard
julliard at winehq.org



More information about the wine-devel mailing list