[PATCH v2] staging: wlags49_h2: strncpy, need checking the memory length

[Chen Gang]

On 05/14/2013 04:13 PM, Dan Carpenter wrote:
> 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".
> 

OK, thanks, "it is only applies to signed variables", so I will send
patch v3 to "cast directly to int".

> 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.

For our case, it is 'unsigned char', so (int)(unsigned int) for
'unsigned char' is always correct. ;)


Thanks.
-- 
Chen Gang

Asianux Corporation