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

[Brett Cannon]

I added the line back in as a comment and if I do this again for py3k I will
do that for all pointer advancement code. That way you guys get your code
for possible future use and I get my compiler silenced and everyone is
happy.

And in case people are being timid in fear of upsetting me, feel free to
undo any changes I made. Obviously I prefer having the lines added back in
as comments so Clang does not complain about them in the future, but if you
simply revert a change I am not going to complain.

On Thu, May 6, 2010 at 05:32, Eric Smith <eric at trueblade.com> wrote:

> 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.
>
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-checkins/attachments/20100506/ecd2cd2d/attachment.html>