search for: newsmallersize

...it() is not called before this object's destructor >> /// is called, the file is deleted in the destructor. The optional >> parameter >> /// is used if it turns out you want the file size to be smaller than >> /// initially requested. >> void commit(int64_t newSmallerSize = -1); >> }; >> >> >> The Flags will probable need to be extended over time to handle other >> clients needs. >> >> For Unix/Darwin, my plan is to implement this by: >> 1) delete the file >> 2) create a new file with a random name in same dir...

...e and deallocates the /// buffer. If commit() is not called before this object's destructor /// is called, the file is deleted in the destructor. The optional parameter /// is used if it turns out you want the file size to be smaller than /// initially requested. void commit(int64_t newSmallerSize = -1); }; The Flags will probable need to be extended over time to handle other clients needs. For Unix/Darwin, my plan is to implement this by: 1) delete the file 2) create a new file with a random name in same directory 3) truncate the file to the new size 4) mmap() in the file r/w 5) On commi...

...ed before this object's destructor >>> /// is called, the file is deleted in the destructor. The optional >>> parameter >>> /// is used if it turns out you want the file size to be smaller than >>> /// initially requested. >>> void commit(int64_t newSmallerSize = -1); >>> }; >>> >>> >>> The Flags will probable need to be extended over time to handle other >>> clients needs. >>> >>> For Unix/Darwin, my plan is to implement this by: >>> 1) delete the file >>> 2) create a new...

.../// buffer.  If commit() is not called before this object's destructor >   /// is called, the file is deleted in the destructor. The optional > parameter >   /// is used if it turns out you want the file size to be smaller than >   /// initially requested. >   void commit(int64_t newSmallerSize = -1); > }; > > > The Flags will probable need to be extended over time to handle other > clients needs. > > For Unix/Darwin, my plan is to implement this by: > 1) delete the file > 2) create a new file with a random name in same directory > 3) truncate the file to the...

...If commit() is not called before this object's destructor > + /// is called, the file is deleted in the destructor. The optional parameter > + /// is used if it turns out you want the file size to be smaller than > + /// initially requested. > + virtual error_code commit(int64_t newSmallerSize = -1); Why is this virtual? I don't ever see a need to subclass FileOutputBuffer. > + /// If this object was previously committed, the destructor just deletes > + /// this object. If this object was not committed, the destructor > + /// deallocates the buffer and the target file...

I now have an implementation of FileOutputBuffer (OutputBuffer was already taken). The patch supports the functionality listed below and I've tested that it works for lld. -------------- next part -------------- A non-text attachment was scrubbed... Name: FileOutputBuffer.patch Type: application/octet-stream Size: 25308 bytes Desc: not available URL:

...le and deallocates the /// buffer. If commit() is not called before this object's destructor /// is called, the file is deleted in the destructor. The optional parameter /// is used if it turns out you want the file size to be smaller than /// initially requested. void commit(int64_t newSmallerSize = -1); }; The Flags will probable need to be extended over time to handle other clients needs. For Unix/Darwin, my plan is to implement this by: 1) delete the file 2) create a new file with a random name in same directory 3) truncate the file to the new size 4) mmap() in the file r/w 5) On commi...

...t; /// buffer. If commit() is not called before this object's destructor > /// is called, the file is deleted in the destructor. The optional parameter > /// is used if it turns out you want the file size to be smaller than > /// initially requested. > void commit(int64_t newSmallerSize = -1); > }; > > > The Flags will probable need to be extended over time to handle other clients needs. > > For Unix/Darwin, my plan is to implement this by: > 1) delete the file > 2) create a new file with a random name in same directory > 3) truncate the file to th...

On May 3, 2012, at 6:10 PM, Nick Kledzik wrote: > Existing llvm code tends to use raw_ostream for writing files. But raw_ostream is not a good match for a linker for a couple of reasons: > > 1) When the linker creates an executable, the file needs the 'x' bit set. Currently raw_fd_ostream has no way to set that. If this were the only problem, I'd suggest just generalizing

Existing llvm code tends to use raw_ostream for writing files. But raw_ostream is not a good match for a linker for a couple of reasons: 1) When the linker creates an executable, the file needs the 'x' bit set. Currently raw_fd_ostream has no way to set that. 2) The Unix conformance suite actually has some test cases where the linker is run and the output file does exists but is not