On 7/20/08, Jon Smirl <[EMAIL PROTECTED]> wrote: > On 7/20/08, Ben Dooks <[EMAIL PROTECTED]> wrote: > > On Sat, Jul 19, 2008 at 08:46:41PM -0400, Jon Smirl wrote: > > > There are a lot places in the i2c API where int is used when the > > > parameter can't be negative. For example, there are more.... > > > > > > /* > > > * The master routines are the ones normally used to transmit data to > devices > > > * on a bus (or read from them). Apart from two basic transfer > functions to > > > * transmit one message at a time, a more complex version can be used to > > > * transmit an arbitrary number of messages without interruption. > > > */ > > > extern int i2c_master_send(struct i2c_client *,const char* ,int); > > > extern int i2c_master_recv(struct i2c_client *,char* ,int); > > > > > > /* Transfer num messages. > > > */ > > > extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg > > > *msgs, int num); > > > > > > u8 level; /* nesting level for lockdep */ > > > > > > > > > Wouldn't these generate more efficient code if switched to uints? > > > > > > I'm not sure, most of the time there's not a lot of difference > > between the signed and unsigned case. If you can provide an example > > of where this is actually true then I would be interested to see... > > > Assigning between lengths causes sign extended instructions. Mixing > signed and unsigned in expressions can cause them too. > > You get the best code generation by using int or unsigned int as > appropriate and supplying the compiler with the correct description of > the variable.
The compiler is also able to catch more errors. If the math can only yield a negative result and it is being compared to a unsigned int, you'll get compiler errors like " expression is constant". > > > > > > Technically, an unsigned int or simply an unsigned would be a > > reasonable change given that you can't really have a minus number > > of transfers. > > > > > > -- > > Ben ([EMAIL PROTECTED], http://www.fluff.org/) > > > > 'a smiley only costs 4 bytes' > > > > > > -- > Jon Smirl > [EMAIL PROTECTED] > -- Jon Smirl [EMAIL PROTECTED] _______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
