search for: archpath

On Nov 22, 2005, at 19:10, Reid Spencer wrote: > 1. What is the path name associated with TmpArchive? If its the same > as the path name associated with archPath then that's a bug, probably > introduced when Path::makeUnique is called from > Path::createTemporaryFileOnDisk which is called from line 377 of > ArchiveWriter.cpp. This does not appear to be the problem. I excluded the lines from the strace that created this temporary file. Afte...

...Path::makeUnique, which is system dependent. I don't have a debugging environment handy to track this down, but I would suggest that you break out a debugger and investigate the following: 1. What is the path name associated with TmpArchive? If its the same as the path name associated with archPath then that's a bug, probably introduced when Path::makeUnique is called from Path::createTemporaryFileOnDisk which is called from line 377 of ArchiveWriter.cpp. 2. If item 1. holds, break in Path::makeUnique and see how it is computing the temporary name. There are three mechanisms: mkstemp,...

Evan Jones wrote: > On Nov 22, 2005, at 19:10, Reid Spencer wrote: > >> 1. What is the path name associated with TmpArchive? If its the same >> as the path name associated with archPath then that's a bug, probably >> introduced when Path::makeUnique is called from >> Path::createTemporaryFileOnDisk which is called from line 377 of >> ArchiveWriter.cpp. > > > This does not appear to be the problem. I excluded the lines from the > strace that...

On Nov 22, 2005, at 17:18, Reid Spencer wrote: > Your patch uses an operating system call that is not portable. All > non-portable code needs to be located in the lib/System library. Yep! I know. That is why I posted it for discussion. I'm not sure if this is the "right" way to fix the problem, or if there is a different fix that should be applied (like perhaps copying the

On Nov 22, 2005, at 23:59, Reid Spencer wrote: >> = {0, >> 0, 4, 0}}} >> (gdb) p archPath >> $3 = {path = {static npos = 4294967295, >> _M_dataplus = {<allocator<char>> = {<No data fields>}, >> _M_p = 0x83545f4 "temp.GNU.a5\b"}, static _S_empty_rep_storage = > What's with the "5\b" at the end? Looks like garbage to...

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached