|
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.
Regards,
Andreas
-- Those who live by the sword get shot by those who don't.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk