Bad coding style of kernel32/pipe tests

Sebastian Lackner sebastian at
Tue Aug 5 13:46:11 CDT 2014


I would like to submit some new tests for kernel32/pipe, but I don't really know
how to deal with the existing ones. To show what I mean a few examples should be

--- snip ---
            if (readden != sizeof(obuf))  /* Linux only returns the first message */
                ok(readden == sizeof(obuf) + sizeof(obuf2), "peek3 got %d bytes\n", readden);
                todo_wine ok(readden == sizeof(obuf) + sizeof(obuf2), "peek3 got %d bytes\n", readden);
        if (avail != sizeof(obuf)) /* older Linux kernels only return the first write here */
            ok(avail == sizeof(obuf) + sizeof(obuf2), "peek3 got %d bytes available\n", avail);
--- /snip ---

There are several such tests, which basically always succeed. I can understand that
all these if(...)s were added to avoid test failures ... but I don't think its really
useful - especially not when the ifs depend on the actual test result, and not the
platform which causes the issues. :/

Before I start submitting additional tests I would like to know how to deal with all
these problems. Should my new tests also contain if(...) blocks around every test, which
could fail on old/new kernels, on MacOS, on FreeBSD, ...?
Hopefully you'll all agree that we have to find a better solution for that ... some
possible ideas:

* Write the tests in such a way, that there are no test failures on Alexandre's main
Linux development machine. Accept test failures for all other Linux/MacOS/FreeBSD/...

* Add additional todo_mac, todo_linux, ... macros, and define WINETEST_PLATFORM to
something a bit more specific than just "wine". todo_wine would mean that it is a todo
on all platforms supported by Wine. This doesn't solve the problems with old/new kernels

* Try to detect MacOS somehow else directly in the test (what would be the recommended
way?) and use if(...)s based on that condition, instead of the test result. This also
provides no solution for old/new kernels ...

I'm also open for additional suggestions if someone has a good idea. I would especially
like to hear, that the solution is _not_ that every Wine developer always has to check
all possible platforms before submitting tests, which can easily get very complicated...


BTW: For those that are interested in the details where I'm working on, just take a
look at: ;)

More information about the wine-devel mailing list