comparision between signed and unsigned
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
RE: comparison between signed and unsigned
Hi Anders.
Quoted 7 lines
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
Hello there Riley,
[snip: compile warnings compare signed to unsigned]
Quoted 5 lines
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
Quoted 8 lines · Anders Karlsson
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