comparision between signed and unsigned

comparision between signed and unsigned

[Anders Karlsson]

[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

Hi list,

Sitting here watching the compile output from 2.4.21-rc1-ac4 and
noticing there is a _lot_ of warnings about comparisions between signed
and unsigned values. The question I have is the following. If all the
signed values were modified to unsigned to fix the warnings, how likely
are things to break? Is there any reason to use signed values unless a
specific reason when negative values are required?

/Anders

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

RE: comparison between signed and unsigned

[Riley Williams]

Hi Anders.

 > Sitting here watching the compile output from 2.4.21-rc1-ac4 and
 > noticing there is a _lot_ of warnings about comparisons between
 > signed and unsigned values. The question I have is the following.
 > If all the signed values were modified to unsigned to fix the
 > warnings, how likely are things to break? Is there any reason to
 > use signed values unless a specific reason when negative values
 > are required?

The obvious question is this: How many of those warnings also occur
with the pristine source - i.e., the -rc1 without the -ac4 source. It
would probably be best to wade through the -rc1 sources fixing those
first, then worry about the -ac* sources once those have been merged
in.

Best wishes from Riley.
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24-Apr-2003

RE: comparison between signed and unsigned

[Anders Karlsson]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

Hello there Riley,

[snip: compile warnings compare signed to unsigned]

> The obvious question is this: How many of those warnings also occur
> with the pristine source - i.e., the -rc1 without the -ac4 source. It
> would probably be best to wade through the -rc1 sources fixing those
> first, then worry about the -ac* sources once those have been merged
> in.

If I make an estimate, I would say that a great majority of the warnings
are present wether I compile 2.4.20-SuSE, 2.4.21-rc1 or 2.4.21-rc1-ac4.
This seems to be a common (deliberate?) theme throughout parts of the
kernel tree.

I could quite well go through and start fixing things (despite me not
knowing C particularly well) but I would, by someone who knows the
kernel quite well, appreciate an estimate of how likely the result is to
be horribly broken.

As I see it, there might be instances where the comparision between a
signed value and an unsigned value could produce a defect. If people
think this is a good thing to fix and there are people that would accept
patches in normal diff -u format, I could spend some time trying to fix
part of this.

Regards,

/Anders

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: comparision between signed and unsigned

[Alan Cox]

On Sul, 2003-05-04 at 10:32, Anders Karlsson wrote:
> Hi list,
> 
> Sitting here watching the compile output from 2.4.21-rc1-ac4 and
> noticing there is a _lot_ of warnings about comparisions between signed
> and unsigned values. The question I have is the following. If all the
> signed values were modified to unsigned to fix the warnings, how likely
> are things to break? Is there any reason to use signed values unless a
> specific reason when negative values are required?

There has been some work done checking entries for errors in 2.4 and
fixing a few real errors. As to others, its mostly gcc being excessively
noisy by default.

If you want to work on them do it on 2.5 though