ws2_32: Add support for FROM_PROTOCOL_INFO to WSASocket()

[Kai Blin]

On Monday 26 May 2008 05:08:46 Dmitry Timoshkov wrote:
> "Kai Blin" <kai.blin at gmail.com> wrote:
> > > > +    {FROM_PROTOCOL_INFO, FROM_PROTOCOL_INFO},
> > > >  };
> > >
> > > Although it was the case before, it's a mistake to have a comma after
> > > the last struct member initializer.
> >
> > It is?  K&R seems to use both, so I preferred to keep it similar to all
> > the other struct member initializers.
>
> I said "a mistake" not "an error". Although the compiler forgives this,
> what the last comma is serving for?

The C grammar printed in my edition of K&R says the following about 
initializers

initializer:
	assignment-expression
	{ initializer-list }
	{ initializer-list , }

so it looks like it's in the C standard that both are perfectly valid. I used 
the perfectly valid form the rest of the file uses.

> > > > +    if (lpProtocolInfo) {
> > > > +      if (af == FROM_PROTOCOL_INFO)
> > > > +          af = lpProtocolInfo->iAddressFamily;
> > > > +      if (type == FROM_PROTOCOL_INFO)
> > > > +          type = lpProtocolInfo->iSocketType;
> > > > +      if (protocol == FROM_PROTOCOL_INFO)
> > > > +          protocol = lpProtocolInfo->iProtocol;
> > >
> > > Please keep opening brace style/indentation consistent with code you
> > > have removed.
> >
> > The function is a mess with brace style and indentation. I've used the
> > same indentaion as the if right above this one. The function wildly mixes
> > two-space, three-space and four-space indents. In this case, I used
> > two-space indents for the outer if and four-space indents for the inner
> > ifs for better readability.
>
> Even if the overall style is a mess it's not a solution to add the code
> which mixes 2 and 4 spaces indentation, and the code you have removed used
> a consistent style.

Ok. Fine. How about we finally agree on a coding standard, document that 
somewhere and require all new patches to conform to that? Then at least one 
wouldn't have to guess which broken indentation/braces to follow.

> > PSDK has the AF_*, PF_*, SOCK_* and IPPROTO_* defines in winsock2.h as
> > well, Wine hasn't. I preferred to keep them together.
>
> How much efforts would it take to put 1 line to a proper .h file?

You're not even looking at what I wrote, are you? FROM_PROTOCOL_INFO is used 
like an address family define, and I tried to keep all of them together.

> All the patches sent to wine-patches fix a bug, not of them are applied due
> to different reasons. You are not a first timer, and know the rules.

What rules are you referring to? The rule that says when adding code to a file 
that has no obvious dominating code style, I should pick the code style from 
below the code I add not the code style from above the code I add? I didn't 
know that one.

I welcome code review that points out errors in my code. Code review that 
alternates between requiring me to be "formally correct" and "consistent to 
the code" in a seemingly random fashion is different.

So you don't care about this patch because you don't have a customer who needs 
it, I don't care about this patch because I can spend my free time on other 
things. Let's just drop it then.

Kai

-- 
Kai Blin
WorldForge developer  http://www.worldforge.org/
Wine developer        http://wiki.winehq.org/KaiBlin
Samba team member     http://www.samba.org/samba/team/
--
Will code for cotton.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20080526/392fd4be/attachment.pgp