"Dimitrie O. Paun" dpaun@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.