On Mon, Aug 20, 2012 at 1:28 PM, Spencer Oliver <[email protected]> wrote: > On 20 August 2012 12:14, Freddie Chopin <[email protected]> wrote: >> >> You suggest this commit should be reverted as a temporary fix for the >> problem before the release? >> >> 4\/3!! >> > > if the commit is reverted then the random segfault will reappear for < > 32bit reads. > we really need a proper fix. >
What is the problem here? Why is the current code destroying data? Do we have to scan all 32 bits, even though the client only requests less? And we don't have anywhere to store all 32 bits since Øyvind removed the "unnecessary" API functions in 991ed5a? And a temporary stack buffer won't work because the transfer is performed after the return so your patch is broken? In that case, we could split the scan field in two, one that stores data in client memory, and another that scans but discards the remaining bits. The endianness callback have to cope with less-than-32-bits swapping, but maybe it does already. /Andreas ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
