Patch to allow bjam bootstrap on WIN64

Hey guys,
I was toying around with bjam from CVS today and I noticed
that
jam0.exe would crash when built for x64.

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).

This patch make the bootstrap succeed with a x64 cl, but
I'm not
entirely sure it's correct for 32-bit compilation.

Best regards,
Andreas

Index: pathunix.c
============================================================
=======
RCS file: /cvsroot/boost/boost/tools/jam/src/pathunix.c,v
retrieving revision 1.15
diff -u -r1.15 pathunix.c
--- pathunix.c  5 Nov 2005 07:05:28 -0000       1.15
+++ pathunix.c  21 May 2006 11:09:01 -0000
 -287,11
+287,11 
  DWORD ShortPathToLongPath(LPCTSTR lpszShortPath,LPTSTR
lpszLongPath,DWORD
                           cchBuffer)
 {
-    DWORD i=0;
+    LONG i=0;
     TCHAR path[_MAX_PATH]=;
     TCHAR ret[_MAX_PATH]=;
-    DWORD pos=0, prev_pos=0;
-    DWORD len=_tcslen(lpszShortPath);
+    LONG pos=0, prev_pos=0;
+    LONG len=_tcslen(lpszShortPath);

     /* Is the string valid? */
     if (!lpszShortPath) {

-- 
Those who live by the sword get shot by those who don't.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

On Sunday 21 May 2006 15:14, Andreas Fredriksson wrote:
> Hey guys,
> I was toying around with bjam from CVS today and I
noticed that
> jam0.exe would crash when built for x64.

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

> 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.

Thanks,
Volodya

-- 
Vladimir Prus
http://vladimir_pru
s.blogspot.com
Boost.Build V2: http://boost.org/boost-
build2
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

On 5/25/06, Vladimir Prus <ghostcs.msu.su> 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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build