[Python-checkins] r80809 - python/trunk/Objects/floatobject.c

Eric Smith eric at trueblade.com
Thu May 6 14:32:31 CEST 2010


Mark Dickinson wrote:
> On Wed, May 5, 2010 at 9:16 PM, brett.cannon <python-checkins at python.org> wrote:
>> Author: brett.cannon
>> Date: Wed May  5 22:16:09 2010
>> New Revision: 80809
>>
>> Log:
>> Remove an unneeded variable increment.
>>
>> Found using Clang's static analyzer.
>>
>>
>> Modified:
>>   python/trunk/Objects/floatobject.c
>>
>> Modified: python/trunk/Objects/floatobject.c
>> ==============================================================================
>> --- python/trunk/Objects/floatobject.c  (original)
>> +++ python/trunk/Objects/floatobject.c  Wed May  5 22:16:09 2010
>> @@ -2478,7 +2478,6 @@
>>
>>                /* Eighth byte */
>>                *p = flo & 0xFF;
>> -               p += incr;
>>
>>                /* Done */
>>                return 0;
> 
> At the risk of bikeshedding, it's not clear to me that making changes
> like this is necessarily a Good Thing.  In this case, it means (a)
> treating the last byte of the packed float differently from the first
> 7, and (b) breaking an invariant that held previously---namely that at
> the end of that section of code, p points just past the last byte
> written.  Clearly these are very minor issues, and don't affect
> correctness in this case.  But I'd argue that similar changes
> elsewhere could adversely affect future maintenance and/or code
> readability, albeit to a tiny degree.
> 
> IOW, redundancy isn't always a bad thing, especially if it aids
> comprehension for the human code reader.

I agree. I often leave pointers positioned at the next insertion point 
in a buffer, in case I later add code that again inserts into the 
buffer. Surely compilers will optimize this away.

-- 
Eric.


More information about the Python-checkins mailing list