On Tue, Feb 8, 2011 at 5:35 PM, Dan Carpenter <error27@xxxxxxxxx> wrote: > On Tue, Feb 08, 2011 at 02:40:49PM +0100, Belisko Marek wrote: >> On Wed, Jan 26, 2011 at 3:30 PM, Dan Carpenter <error27@xxxxxxxxx> wrote: >> > Also when it does: >> > Â Â Â Âmemcpy(ft1000dev->tx_buf, *pUcFile, byte_length); >> > >> > That should probably be: >> > Â Â Â Âmemcpy(ft1000dev->tx_buf, *pUcFile, word_length * 4); >> No this shouldn't because before you have additional check: >> if (byte_length && ((byte_length % 64) == 0)) >> Â Â Â Â byte_length += 4; >> >> if (byte_length < 64) >> Â Â Â Â byte_length = 68; >> So in my opinion byte_length should stay. > > Yes. ÂWe make byte_length longer than the caller intended. ÂThe caller > knows the size of the source buffer. ÂWe have to pad the length of the > other buffer, but we should fill up the last part with zeroes instead > of reading past the end of the source buffer. > > (I am not very familiar with the code and I haven't looked outside this > function, so I may be wrong). > > Also I really bet that the thing where byte_length can't be a multiple > of 64 is bogus. ÂI've never heard of anything with a requirement like > that. You're right. Today will make test when remove all opaque code. Anyway at the end file position is moved in that way: *pUsFile = *pUsFile + (word_length << 1); *pUcFile = *pUcFile + (word_length << 2); So short pointer multiplied by 2 and char pointer by 4 with word_length. So my assume all check and byte_length increasing is not correct (will see what test shows). > > regards, > dan carpenter > > > regards, marek -- as simple and primitive as possible ------------------------------------------------- Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite icq: 290551086 web: http://open-nandra.com _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
