[Python-checkins] r80809 - python/trunk/Objects/floatobject.c (original) (raw)

Brett Cannon brett at python.org
Thu May 6 19:59:39 CEST 2010

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>

More information about the Python-checkins mailing list