Boost logo

Boost-Build :

From: Andreas Fredriksson (deplinenoise_at_[hidden])
Date: 2006-05-25 06:27:17

On 5/25/06, Vladimir Prus <ghost_at_[hidden]> wrote:

> Hi Andreas,
> thanks for the patch. I've verified that it does not break 32-bit windows, and
> just committed it.

Cool, thanks.

> > It seems the bug is that ShortPathToLongPath function uses DWORDs for
> > indexes while at the same time relying on them wrapping around; this
> > doesn't work well when indices are 64-bit (DWORD is still a 32-bit
> > datatype).
> Can you explain where's relying on wrapping around? I can't find any.

Wrapping was a bad word, but the code does pointer arithmetic with DWORDS:

            /* the path[prev_pos+1]... path[pos] range is the part of
               path we're handling right now. We need to find long
               name for that element and add it. */
            new_element = path + prev_pos + 1;

path is a TCHAR array (so essentially a 64-bit pointer in this expression)
prev_pos was a DWORD (a 32-bit unsigned quantity)
1 is an int (a signed 32-bit quantity)

prev_pos starts at -1 (which is really 0xFFFFFFFFu because DWORD is an
unsigned type)

since + is left-associative, this works out to adding 0xFFFFFFFFu to a
pointer and then adding one to that, so the code would effectively
read and write to a pointer far off the virtual memory space of the
process (2^32 bytes away from the array).

With 32-bit pointers it works because the pointer arithmetic will wrap
around and come back at the array.

Making prev_pos signed solves the problem.


Those who live by the sword get shot by those who don't.

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at