A new demangler test?
Would it be appropriate to add a test to the name demangler that: 1) Scans all '.dll' and '.spac' files for mangled names, and 2) Tries to decode those names. 3) Prints the mangled and decoded names and where they occur. Success would be that all names decode without the decoder blowing up or failing.
Le 21/02/2013 14:33, Max TenEyck Woodbury a écrit :
Would it be appropriate to add a test to the name demangler that:
1) Scans all '.dll' and '.spac' files for mangled names, and
2) Tries to decode those names.
3) Prints the mangled and decoded names and where they occur.
Success would be that all names decode without the decoder blowing up or failing.
adding tests for demangler is good but you just need to have a set of mangled/unmangled strings for the test as core demangler in msvcrt, test should be added here... (but grabbing the mangled strings shall be left out of the test itself) A+
On 02/23/2013 02:54 AM, Eric Pouech wrote:
Le 21/02/2013 14:33, Max TenEyck Woodbury a écrit :
Would it be appropriate to add a test to the name demangler that:
1) Scans all '.dll' and '.spec' files for mangled names, and
2) Tries to decode those names.
3) Prints the mangled and decoded names and where they occur.
Success would be that all names decode without the decoder blowing up or failing.
adding tests for demangler is good but you just need to have a set of mangled/unmangled strings for the test as core demangler in msvcrt, test should be added here... (but grabbing the mangled strings shall be left out of the test itself) A+
One of the important aspects of name demangling is that it should work on _all_ the names in the current system. The current test does demangle a list of known strings, but that list was incomplete with respect to all the features used in real names the last time I dug into the details (which was none too recently). Scanning for all the real mangled names not only makes sure that the demangler is working properly, it also assures that all the names used are properly formed and decode to their intended values.
Le 24/02/2013 07:07, Max TenEyck Woodbury a écrit :
On 02/23/2013 02:54 AM, Eric Pouech wrote:
Le 21/02/2013 14:33, Max TenEyck Woodbury a écrit :
Would it be appropriate to add a test to the name demangler that:
1) Scans all '.dll' and '.spec' files for mangled names, and
2) Tries to decode those names.
3) Prints the mangled and decoded names and where they occur.
Success would be that all names decode without the decoder blowing up or failing.
adding tests for demangler is good but you just need to have a set of mangled/unmangled strings for the test as core demangler in msvcrt, test should be added here... (but grabbing the mangled strings shall be left out of the test itself) A+
One of the important aspects of name demangling is that it should work on _all_ the names in the current system. The current test does demangle a list of known strings, but that list was incomplete with respect to all the features used in real names the last time I dug into the details (which was none too recently).
Scanning for all the real mangled names not only makes sure that the demangler is working properly, it also assures that all the names used are properly formed and decode to their intended values.
I'm just saying that the test shouldn't embed the way to grab the mangled names it should be made outside of the test A+
On 2/24/2013 10:07, Max TenEyck Woodbury wrote:
On 02/23/2013 02:54 AM, Eric Pouech wrote:
Le 21/02/2013 14:33, Max TenEyck Woodbury a écrit :
Would it be appropriate to add a test to the name demangler that:
1) Scans all '.dll' and '.spec' files for mangled names, and
2) Tries to decode those names.
3) Prints the mangled and decoded names and where they occur.
Success would be that all names decode without the decoder blowing up or failing.
adding tests for demangler is good but you just need to have a set of mangled/unmangled strings for the test as core demangler in msvcrt, test should be added here... (but grabbing the mangled strings shall be left out of the test itself) A+
One of the important aspects of name demangling is that it should work on _all_ the names in the current system. The current test does demangle a list of known strings, but that list was incomplete with respect to all the features used in real names the last time I dug into the details (which was none too recently).
Scanning for all the real mangled names not only makes sure that the demangler is working properly, it also assures that all the names used are properly formed and decode to their intended values. I don't see a point to extend test data that much, it's enough to add some most common cases, and add more when something breaks because of it. Otherwise it doesn't deserve that much of attention imho.
By the way, do you see something broken or it's just something you want to work on?
On 02/24/2013 04:18 AM, Nikolay Sivov wrote:
By the way, do you see something broken or it's just something you want to work on?
Partly broken. If fed a bad string, it sometimes blows up and sometimes returns an error code. The 'real' routine also blows up on some strings. Which strings depends on the windows version. That means there is no specific bug we have to match, so it would make sense to do it right (that is return an error code) in all cases. Is that OK? In my opinion, the search for names is fairly important, but it may not belong in a msvcrt test. It might be better as part of a dbghelp test or in some other utility test. That search should work in a windows environment as well as a Wine environment. It should almost certainly check all the '.dll's in 'C:\windows\system*' and possibly a few other places where mangled names are likely to be found... But I have to admit, it is also something I want to work on...
While this may be a useful exercise (and I'd personally like to see some demangler improvements, particularly support for managed references), this sort of broad test doesn't make sense for the Wine test suite, especially if we can't be sure it will always work on Windows. It's the sort of thing you could use to detect problems with our code, which you could then add a few individual tests for. Maybe it could be added to winezeug? Or is there a more appropriate place?
participants (4)
-
Eric Pouech -
Max TenEyck Woodbury -
Nikolay Sivov -
Vincent Povirk