Re: [srecord-users] [PATCH 4/4] Fix -crop up to the last address

[Scott F. <sfi...@ip...>]

This is a great collection of patches Markus (and some good pointers to others). 
I'll get them integrated once my day job settles back to a manageable level.

Cheers,
Scott

On 12/08/14 19:58, Markus Heidelberg wrote:
> Am Dienstag, 12. August 2014, 11:42:52 schrieb Markus Heidelberg:
>> Can be reproduced with this command:
>> srec_cat -generate 0xFFFFFFE0 0x100000000 -constant 0 -crop 0xFFFFFFF0 0x100000000 -o - -hex-dump
>>
>> Giving this error:
>> srec_cat: srecord/record.cc:65: srecord::record::record(srecord::record::type_t, srecord::record::address_t, const data_t*, size_t): Assertion `length <= max_data_length' failed.
>> ---
>>
>> diff --git a/srecord/input/filter/crop.cc b/srecord/input/filter/crop.cc
>> index a2b79ba..4d432ac 100644
>> --- a/srecord/input/filter/crop.cc
>> +++ b/srecord/input/filter/crop.cc
>> @@ -116,8 +116,8 @@ srecord::input_filter_crop::read(srecord::record &record)
>>           //
>>           // Construct the return record from the data held.
>>           //
>> -        unsigned long lo = fragment.get_lowest();
>> -        unsigned long hi = fragment.get_highest();
>> +        interval::data_t lo = fragment.get_lowest();
>> +        interval::data_t hi = fragment.get_highest();
>>           record =
>>               srecord::record
>>               (
>
> A note to this change:
> On my 64 bit machine sizeof(unsigned long) is 8, whereas
> interval::data_t is 4 (typedef to uint32_t). The difference "hi - lo"
> (where hi was 0) some lines below was calculated wrong then. With the
> correct type there is no wrong overflow.
>
> It is basically the same as the intended overflow in the addition in
> patches 1-3. This also only works if using the correct type.
>
> There are some other places in the source code with this potential
> problem that this patch fixed, but I haven't checked them yet.
> Searching for get_lowest() and get_highest() will lead to some.
>
> Markus
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> srecord-users mailing list
> sre...@li...
> https://lists.sourceforge.net/lists/listinfo/srecord-users
>