ws2_32: Invert SIOCATMARK logic

[Bruno Jesus]

André Hentschel once tried to fix this in wine but his change was
denied due to the lack of tests and docs.
Now here I am trying to fill the gaps and fix this wrong behavior to
match the windows sockets implementation more closely.

The patch simply inverts the logic of SIOCATMARK return so that 4
todos are removed in the trade of adding 2 new todos. Please, don't
stop reading as you probably already thought after reading the
previous sentence.

It's well know that SIOCATMARK works in a different way in windows and
*nix. The proof can be found in any *nix man and in msdn and other
internet pages:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms741621%28v=vs.85%29.aspx
...If no OOB data is waiting to be read, the operation returns TRUE...

http://linux.die.net/man/7/tcp
...Returns true (i.e., value is nonzero) if the inbound data stream is
at the urgent mark...

Windows returns TRUE if no OOB data exists (NOMARK), while *nix
returns TRUE if the recv queue is in the mark.

By reversing the return value from SIOCATMARK we can match the windows
behavior more closely as the fixed todos show. The other 2 tests (that
need a new todo) were working by accident.

As a matter of documentation It's possible to make Linux behave more like
windows by changing a kernel parameter as follows:

Make the compatibility with Windows less problematic (behave more like RFC1122):
echo 1 > /proc/sys/net/ipv4/tcp_stdurg

Restore BSD behavior (behave more like RFC793)
echo 0 > /proc/sys/net/ipv4/tcp_stdurg

If the tcp_stdurg is set to 1 the test from line 528 (now a 'todo')
passes showing that this option makes linux behave more like windows
proving the RFC differences stated in
http://tangentsoft.net/wskfaq/newbie.html chapter 2.17 (next to last).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ws2_32-Invert-SIOCATMARK-logic.patch
Type: text/x-diff
Size: 4084 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-patches/attachments/20111119/b17dbed4/attachment-0001.patch>