[PATCH] Fixed some bugs due to pointer overflow undefined behavior

Eric Lubin ecbtln at gmail.com
Thu Dec 5 17:56:05 CST 2013


I believe UINTPTR_MAX is included from the same file as INT_MAX (<stddef.h>) which is used elsewhere in parsers.c. Restructuring the code to include a counter would work as well, I just wanted to make this know that the check for pointer overflow does not even get called in its current form

Eric

On Dec 5, 2013, at 6:38 PM, Matt Mackall <mpm at selenic.com> wrote:

> On Thu, 2013-12-05 at 14:23 -0800, Eric Lubin wrote:
>> # HG changeset patch
>> # User Eric Lubin <eric at lubin.us>
>> # Date 1386282190 28800
>> # Node ID 005a0b96477ed6cde4e880861c9e7a2239ed7770
>> # Parent  1c92524c37cdd251c1a36b2da0fb4148b0e6ba09
>> Fixed some bugs due to pointer overflow. In the four cases fixed, the developer wrote a check to see if the sum of a pointer and a positive number was less than the value of the pointer, intending to check for pointer overflow. Unfortunately, pointer overflow is undefined behavior in c, so the compiler is free to optimize out this overflow check. I replaced these checks with safer checks that comply with the C standard and won't get optimized out.
> 
> See ContributingChanges for how we like to format commit messages. One
> extremely long line tends to create problems, as you'll see in the
> subject line.
> 
> I'm a bit worried about the portability of UINTPTR_MAX. It'd probably be
> easier if we just did away with pointer comparisons entirely and track
> whether we were inside the target data with integers. For instance, by
> changing the end variable to a remain counter.
> 
> -- 
> Mathematics is the supreme nostalgia of our time.
> 
> 



More information about the Mercurial-devel mailing list