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

[Ishai Rabinovitz]

Another option may be to use Hungarian notation for this issue.
Let's decide that all network order variables will start by n_ (It is
also possible to use h_ for host order variables - only for the variable
that originally came from the wire or will eventually be sent on the
wire)
This will make it easy to follow the content of the variables without
changing the types.
I'm using this notation on my code and it makes my life much easier.

Ishai

> -----Original Message-----
> From: ofw-bounces at lists.openfabrics.org 
> [mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Leonid Keller
> Sent: Wednesday, July 02, 2008 8:04 PM
> To: Fab Tillier; Sean Hefty; ofw at lists.openfabrics.org
> Subject: RE: [ofw] [RFC] [PATCH 2/3] winmad userspace library
> 
> 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
> > 
> _______________________________________________
> ofw mailing list
> ofw at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
>