[PATCH 1/3] ntdll/tests: Add tests for RtlIpv4StringToAddressEx, RtlIpv6StringToAddress (try 2)
stefandoesinger at gmail.com
Thu Feb 19 04:36:58 CST 2015
-----BEGIN PGP SIGNED MESSAGE-----
Am 2015-02-19 um 11:00 schrieb Mark Jansen:
> I do not agree with this (combining the test into one table): Any
> sensible implementation will have the Ex function call the non-Ex
> function to handle the ip parsing part,
The way the terminator parameter works is a strong indicator of that,
yeah. But the usual way is for the non-Ex function to call the Ex one.
Microsoft also loves to duplicate code and functionality (see e.g. gdi
vs gdiplus vs dwrite). I guess our implementation can be built that
way, but I don't think the tests should be written based on that
assumption. Instead, the tests should try their best to show that this
is how the relation between base and ex works.
I guess the "terminator" output helps the caller (in your case the -Ex
function) find out how many characters the base function read and
where it has to look for the port. Though there are still some
potential trouble cases like "192.168.0.1 :80"
> in which case it does not serve any purpose to run all tests again
> for the Ex function (essentially just re-testing the non-Ex
Running the extra tests is not much of a problem. And the full set of
tests needs to be written anyway.
> Besides that, sharing the table between the functions means having
> separate results for the Ex and non-Ex in the same table, and what
> is the point of one shared table then?
If there is no reusable overlap then it obviously makes no sense. But
my understanding is that for any input that does not contain a port,
non-ex and -ex will behave in the same way. So I expect that you can
share IP address based tests like 2184.108.40.206 between both. You have to
test how the non-ex version reacts to port information - these sets of
input data are needed for both versions too. That will mostly be the
success cases of the -Ex tests.
Of course there will be some tests (e.g. port corner cases that fail
in -Ex) that only make sense for the Ex version. I don't see a problem
with running them against the base version and checking that you
indeed get STATUS_INVALID_PARAMETER back.
Fwiw, if you still think that merging the tables doesn't make sense
I'll trust you on that - after all, you are writing the code. But
please give it some serious thought.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
More information about the wine-devel