[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