[Nut-upsdev] gcc4 compiler warnings

Charles Lepple clepple at gmail.com
Fri Feb 10 12:29:01 UTC 2006


On 2/10/06, Arjen de Korte <nut+devel at de-korte.org> wrote:
>
> > On Thu, 9 Feb 2006, Charles Lepple wrote:
> >
> >> On 2/9/06, Arjen de Korte <nut+devel at de-korte.org> wrote:
> >>> This is due to the fact that some drivers need to pass character values
> >>> between 0x80 and 0xFF to or from the drivers, but the serial functions
> >>> use
> >>> signed chars. Unless some drivers use negative values, my preference
> >>> would
> >>> be to fix/create serial functions (to use unsigned chars), rather than
> >>> to
> >>> convert the characters between 0x80 and 0xFF to negative numbers.
> >>> Especially where status bits are used, listing a hex value is more
> >>> readable then.
> >>
> >> I tend to agree with Arjen on this one - most drivers will be treating
> >> characters as unsigned, since the majority of the values being
> >> returned are unsigned.
> >
> > Indeed. It didn't even occur to me that the serial functions might use
> > signed char for input/output. I'm all for fixing this the proposed
> > (==right) way.
>
> In that case, how are we going to implement this? Modify the existing
> drivers to use unsigned char for all communication with the UPS or create
> new ones? Be aware that some drivers use string operations on the results
> received from the UPS (strlen or strcmp for instance) and will require
> typecasting there (char *). Otherwise we're in for a lot more compiler
> warnings from string operations.

OK, now I'm starting to see the value of separate functions for
unsigned char results.. (It would probably be best if they were
inline...)

What worries me is that in the push to reduce the number of warnings,
drivers are converted without testing to see if they are actually
affected by the change.

> Nevertheless, I would prefer typecasting (unsigned char *) to (char *)
> over the reverse, since string operations are usually performed on (7 bit)
> ASCII text only, where there is no real difference between using unsigned
> and signed chars.

Speaking of which, are there any cases where UTF-8 would cause
problems? In most cases where string comparisons are being used, the
UPS should be sending 7-bit values, so this may not be an issue.

--
- Charles Lepple



More information about the Nut-upsdev mailing list