wine/ library/debug.c include/wine/library.h i ...

[Alexandre Julliard]

"Dimitrie O. Paun" <dpaun at rogers.com> writes:

> Well, I've tried the dump-directly-to-output version, and it invariably
> leads to ugly code. The usage of debuglvitem_t is _so_ much nicer
> compared to anything else. And uniform. And easy to understand.
> Granted, the function is a bit big, but the resulting string is not
> that 'huge'. In fact, the function is big because I'm trying to minimize
> the string (and thus uncluttered the output). The max_size of 200 that we 
> have now is more than enough for anything we need. As for the lifetime
> of the string, it's _identical_ to the RECT, POINT, and SIZE ones.

Not really; it's doing a lot more stuff between the time the string
would be allocated and the time it is printed, even including other
buffer allocations which would make it impossible to release the
unneeded string space. If you don't want to make it dump directly to
the output, you could put things into a stack buffer and then do a
wine_dbg_sprintf to copy that buffer into the strings space.

> On the other hand, cluttering all on Wine's code with wine_* and WINE_TRACE,
> and WINE_ERR, is not also very appealing either. Look, let's not try to
> solve world's problems: this is not the debugging API to end all debugging
> APIs. It's Wine's internal one. And it's present interface is _nice_, and
> easy to use.

The thing is that it's not only internal, it's useful in Winelib apps
because there are no good debugging functions in the Windows API. And
everybody I know who has tried to use the debug API in a Winelib app
has been confused by the different names.

Now I'm not saying we should rename TRACE everywhere, but for new
functions, especially ones that aren't used all that much, I don't
think an extra 'wine' prefix is a problem, and it makes things a lot
easier to follow.

-- 
Alexandre Julliard
julliard at winehq.com