[ofw] [RFC] [PATCH 2/3] winmad userspace library

[Leonid Keller]

Sorry, guys, but I strongly disagree.
Pkey is the only example.
And, btw, when I prepared the first pkey patch with the changes at the
very low level,
you (Fab) suggested to change the types all over the way. :(
And I agree with you here.

Why do we use types like INT32 and int while anyone knows that it's the
same thing ?
Because it gives a bit more info which means that one has to remember
less things.
It's a fault of Windows, that they didn't define network types.
Now they have to remind in all places "port_number in socket_addr is in
network order " and so forth.
We do not usually use signed network types, so we are talking about 3
typedefs !
And, once more, editors and debugger show the type and not the comment.
It is good to stick to existing interfaces, but in practice it means,
that you will have to *remember*, that these 30 fields are in network
order.
And one more argument.
When I was porting stuff from Linux to Windows, I have several errors
just propagating parameters from user to kernel because in user space
they were defined as little endian types, while in kernel - as network
types.
It's a wrong programming practice IMO.

So I re-iterate my suggestion !  

> -----Original Message-----
> From: Fab Tillier [mailto:ftillier at windows.microsoft.com] 
> Sent: Wednesday, July 02, 2008 7:36 PM
> To: Sean Hefty; Leonid Keller; ofw at lists.openfabrics.org
> Subject: RE: [ofw] [RFC] [PATCH 2/3] winmad userspace library
> 
> >> I'd suggest to change all the types, that are in network 
> order, into 
> >> network ones, like it is done in all the stack.
> >> If you don't like IBAL names, define something like typedef UINT32 
> >> UNET32;
> >>
> >> Using comments for the fields in the structures (like '// Network 
> >> byte
> >> order') is not enough error prone, IMO. You will have 
> parameters and 
> >> variables, that are to be assigned to these fields and you 
> will not 
> >> always look into the structure and notice the comment. 
> Also editors 
> >> and debuggers show you the type of variable, not the comment ... :(
> >>
> >> I'd like to see this change applied to all of your code (WinVerbs, 
> >> libumad, drivers ...)
> >  I'm not disagreeing that this isn't useful, but I'd like 
> to keep the 
> > interfaces consistent with other Windows APIs.  I'm not 
> aware of any 
> > Window data types like be_32.  (I looked, but maybe I 
> missed it.)  Are 
> > there any existing Windows APIs (from MS) that define types 
> like this?
> 
> I'm not aware of any and I'd probably prefer just sticking 
> with the existing Windows types.  Having network order types 
> isn't fool proof: recall the recent issue with pkey byte 
> ordering.  The compiler doesn't provide any help here either, 
> because UINT32 and UNET32 are the same underlying type.
> 
> -Fab
>