Warning messages during compilation of 2.4.21. (5 files)

Ishikawa (ishikawa@yk.rim.or.jp)
Sun, 22 Jun 2003 05:01:17 +0900

Hi,

I patched my local kernel source to 2.4.21
and compiled it using gcc on my Debign GNU/Linux system.

I recorded the compile session found a few warning messages which caught
my
eyes.
(These are aside from the usual "defined but not used" warnings,
and a host of warnings caused by the particular style of
assembly language source in boot setup.S.
They are harmless, I believe.)

There are five files which produced the relevant warnings, which
I will explain below, in total. Considering the sheer number of
files in the kernel, this number is very small.
Thanks to all the contributors and Marcello to put such a
fine distribution. I hope my comment below reduces the warning
messages still further.

Environment.

Kernel 2.4.21 source.

GCC: gcc --version
gcc (GCC) 3.3 (Debian)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

I will explain the five files and warning messages in turn.

---


[1] /usr/src/linux/drivers/char/agp/agpgart_be.c
;;;MODULE_AUTHOR("Jeff Hartmann <jhartmann@precisioninsight.com>");




agpgart_be.c: In function `agp_generic_create_gatt_table':
agpgart_be.c:580: warning: assignment from incompatible pointer type
agpgart_be.c: In function `amd_create_gatt_table':
agpgart_be.c:2453: warning: assignment from incompatible pointer type
agpgart_be.c:2454: warning: assignment from incompatible pointer type
agpgart_be.c: In function `amd_free_gatt_table':
agpgart_be.c:2480: warning: assignment from incompatible pointer type
agpgart_be.c:2481: warning: assignment from incompatible pointer type


There are three chunks. I will investigate this in turn.
(All of them seem to be fixed by (void *) cast on the Right-Hand-Side
of assignments.)


[]  agpgart_be.c:580: warning: assignment from incompatible pointer type


	char *table;
           ...
580 -->	agp_bridge.gatt_table_real = (unsigned long *) table;
	agp_gatt_table = (void *)table;


(It looks to me simply change the cast on the Right-Hand-Side into
           (void *) would disable the warning?)


The struct member gatt_table_real is declated as pointer to u32.
cd /usr/src/linux/drivers/char/agp/
grep -n  -e gatt_table_real *.h /dev/null
agp.h:88:	u32 *gatt_table_real;


Solution. Change the (unsigned long *) cast on the RHS to (void *).


[] agpgart_be.c:2453: warning: assignment from incompatible pointer type
   agpgart_be.c:2454: warning: assignment from incompatible pointer type


-->	agp_bridge.gatt_table_real = page_dir.real;
-->	agp_bridge.gatt_table = page_dir.remapped;
	agp_bridge.gatt_bus_addr = virt_to_bus(page_dir.real);


Solution.
put (void *) cast on RHS of the assignments.


[]
agpgart_be.c: In function `amd_free_gatt_table':
agpgart_be.c:2480: warning: assignment from incompatible pointer type
agpgart_be.c:2481: warning: assignment from incompatible pointer type




--->	page_dir.real = agp_bridge.gatt_table_real;
--->	page_dir.remapped = agp_bridge.gatt_table;


Solution.
put (void *) on the RHS.



---


The following files keyboard.c and vt.c 
produce warnings in a somewhat convinced manner in that
the warning is produced by explicit checking of
argument values: however as it stands, the 
checking always produce TRUE or FALSE, a compile-time
constant, so to speak.


[2] /usr/src/linux/drivers/char/keyboard.c


keyboard.c: In function `do_fn':
keyboard.c:644: warning: comparison is always true due to limited range
of data type


static void do_fn(unsigned char value, char up_flag)
{
	if (up_flag)
		return;
--->	if (value < SIZE(func_table)) {
		if (func_table[value])
			puts_queue(func_table[value]);
	} else
		printk(KERN_ERR "do_fn called with value=%d\n", value);
}


SIZE is a macro to return the size of an array.


The size of func_table is MAX_NR_FUNC.


cd /usr/src/linux/drivers/char/
grep -n	 -e func_table *.[ch] /dev/null
defkeymap.c:191:char *func_table[MAX_NR_FUNC] = {
		     ...




MAX_NR_FUNC is defined to be 256.
cd /usr/src/linux/include/linux/
grep -n	 -e NR_FUNC *.h /dev/null
kbd_kern.h:11:extern char *func_table[MAX_NR_FUNC];
keyboard.h:32:#define MAX_NR_FUNC	256	/* max nr of strings assigned to
keys */


So the confition inside if() is always TRUE as it stands.


Solution: see below for solution to [3].


[3] /usr/src/linux/drivers/char/vt.c


vt.c: In function `do_kdsk_ioctl':
vt.c:166: warning: comparison is always false due to limited range of
data type
vt.c: In function `do_kdgkb_ioctl':
vt.c:283: warning: comparison is always false due to limited range of
data type


    #define i (tmp.kb_index)
    #define s (tmp.kb_table)
    #define v (tmp.kb_value)


166:
-->    	if (i >= NR_KEYS || s >= MAX_NR_KEYMAPS)
	    	return -EINVAL;	


283:
	if (tmp.kb_func >= MAX_NR_FUNC)
		return -EINVAL;


NR_KEYS is defined as 128.
keyboard.h:18:#define NR_KEYS		128
keyboard.h:28:extern unsigned short plain_map[NR_KEYS];


Solution :


I observe the desire to check the parameter value,
whic probably caused grief in the past.


Maybe cast the value to an integer value to
suppress the warning? It might be a little far-fetched
to do so just to suppress warning messages in
the compilation log, but I can see that for future
qaultiy-assurance of linux kernel efforts, such
hand-twisting may be necessary. 


(for example, the line 283 of vt.c could be re-written to
   int kludge_i; /* to shut up warning */


   if((kludge_i = tmp.kb_func) >= MAX_NR_FUNC)
       return -EINVAL;


OR
In this particular case, 
if we are very sure that MAX_NR_FUNC should not decrease 
from the current value (and is likely so), then
we can do away completely without the
checking that produced the warning messages.
(And to protect the future programmer from breaking
the assumption, we need to put put something like


  #if MAX_NR_FUNC < 256
  #error you lose : must be equal to or larger than 256. 
  #endif


in the keyboard.h)



---


[4] /usr/src/linux/drivers/scsi/sym53c8xx.c
    ;;; <groudier@free.fr>


sym53c8xx.c: In function `sym53c8xx_pci_init':
sym53c8xx.c:13172: warning: integer constant is too large for "long"
type


	/* Configure DMA attributes.  For DAC capable boards, we can encode
	** 32+8 bits for SCSI DMA data addresses with the extra bits used
	** in the size field.  We use normal 32-bit PCI addresses for
	** descriptors.
	*/
	if (chip && (chip->features & FE_DAC)) {
->		if (pci_set_dma_mask(pdev, (u64) 0xffffffffff))
			chip->features &= ~FE_DAC_IN_USE;
		else
			chip->features |= FE_DAC_IN_USE;
	}


Maybe we should write the integer value using "ull" as
0xffFFffFFffull ? (note the "ull" suffix. This shuts up
the warning from GCC and all is well.)




I checked that the GCC certainly suprress the warning with "ull" suffix.
(I have no idea if other compilers follow suit, but
 who wants to compile this piece of code using non-GCC compiler?
 Maybe HP risc folks and pcc folks???)


The following file ymfpci.c puzzles me.
Looks to me that there is indeed a logic  bug or something.


[5] /usr/src/linux/drivers/sound/ymfpci.c
    ;;; zaitcev@yahoo.com ???


ymfpci.c: In function `ymf_ac97_init':
ymfpci.c:2463: warning: comparison is always false due to limited range
of data type


It certainly looks that  something is wrong with the code.
(Maybe some masking of the eid and the immediate value is missing?)


code in question


   u16 eid;
	...


   2462	eid = ymfpci_codec_read(codec, AC97_EXTENDED_ID);
-->2463	if (eid==0xFFFFFF) {
		printk(KERN_WARNING "ymfpci: no codec attached ?\n");
		goto out_kfree;
	}




Solution: ???






----


This is all.
By fixing the above files (except ymfpci.c) in the above,
we can reduce the warning messages during the kernel compile.


I am not on linux-kernel mailing list and so prefer cc: ing if
someone responds to the message.
(I also intend to send a separate message to the module authors
as far as I could find them. I am not sure who are
responsible for vt.c and keyboard.c, though.)




 
Happy Hacking,





-- 
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/