On Tue, May 14, 2013 at 03:54:52PM +0800, Chen Gang wrote: > On 05/14/2013 03:14 PM, Dan Carpenter wrote: > > On Tue, May 14, 2013 at 02:01:50PM +0800, Chen Gang wrote: > >> > > >> > HCF_MAX_NAME_LEN is 32, which may less than ''probe_rsp->rawData[1]'', > >> > so need check the length when copy to ssid. > >> > > >> > Type of 'probe_rsp->rawData[1]' is 'hcf_8' which is 'unsigned char', > >> > better to cast to 'unsigned int' firstly, and then cast to 'int'. > > Why not cast directly to int? It's the same in the end. > > > > For gcc under x86, it's the same in the end. > > But I am not quite sure whether all platforms gcc compilers can get the > correct result, so I use (int)(unsigned int) for 'unsigned char'. > It is always correct if: > only let 'signed' and 'unsigned' cast are in the same type. > only let type cast with the same 'signed' or 'unsigned'. > > In my memory (may during 2006 - 2007 years), for some C compilers, when > cast from 'unsigned char' to 'int' directly, they will let '0xff' to > '0xffffffff'. > No. You're talking about sign expansion and it only applies to signed variables. Perhaps the confusion is that char type can be either signed or unsigned if the sign isn't specified. On x86 a "char" is "signed char" but there are other arches where it is "unsigned char". Also that wouldn't work. Casting a signed char to unsigned int would still result in sign expansion. It would need to be casted to unsigned char first then to int. regards, dan carpenter _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
