search for: outbufend

This code from raw_ostream.h is really racy: raw_ostream &operator<<(StringRef Str) { // Inline fast path, particularly for strings with a known length. size_t Size = Str.size(); // Make sure we can use the fast path. if (Size > (size_t)(OutBufEnd - OutBufCur)) return write(Str.data(), Size); if (Size) { memcpy(OutBufCur, Str.data(), Size); OutBufCur += Size; } return *this; } Of course, one might wonder why someone would need to output to a stream from multiple threads at the same time. But imagine someon...

...racy: > > > > raw_ostream &operator<<(StringRef Str) { > > // Inline fast path, particularly for strings with a known length. > > size_t Size = Str.size(); > > > > // Make sure we can use the fast path. > > if (Size > (size_t)(OutBufEnd - OutBufCur)) > > return write(Str.data(), Size); > > > > if (Size) { > > memcpy(OutBufCur, Str.data(), Size); > > OutBufCur += Size; > > } > > return *this; > > } > > I don’t believe "the is racy” is an app...

...racy: > > > > raw_ostream &operator<<(StringRef Str) { > > // Inline fast path, particularly for strings with a known length. > > size_t Size = Str.size(); > > > > // Make sure we can use the fast path. > > if (Size > (size_t)(OutBufEnd - OutBufCur)) > > return write(Str.data(), Size); > > > > if (Size) { > > memcpy(OutBufCur, Str.data(), Size); > > OutBufCur += Size; > > } > > return *this; > > } > > I don’t believe "the is racy” is an appr...

...hy: + raw_ostream &write(unsigned char C) override { + grow(1); + *OutBufCur++ = C; + return *this; + } Is 3 times as fast as raw_svector_ostream? I don't see a good reason why that should be any faster than: raw_ostream &operator<<(char C) { if (OutBufCur >= OutBufEnd) return write(C); *OutBufCur++ = C; return *this; } You might just be seeing the difference between having write inlined vs. non-inlined, in which case your patch might be a complicated way to pull the likely cases of some raw_ostream methods into the header. -- Sean Silva On T...

...g<128> S; raw_svector_ostream OS(S); OS<< ... Use OS.str() While raw_svector_ostream is smart to share the text buffer itself, it's inefficient keeping two sets of pointers to the same buffer: In SmallString: void *BeginX, *EndX, *CapacityX In raw_ostream: char *OutBufStart, *OutBufEnd, *OutBufCur Moreover, at runtime the two sets of pointers need to be coordinated between the SmallString and raw_svector_ostream using raw_svector_ostream::init, raw_svector_ostream::pwrite, raw_svector_ostream::resync and raw_svector_ostream::write_impl. All these functions have non-inlined imple...

...gt;> While raw_svector_ostream is smart to share the text buffer itself, it's >>>> inefficient keeping two sets of pointers to the same buffer: >>>> >>>> In SmallString: void *BeginX, *EndX, *CapacityX >>>> In raw_ostream: char *OutBufStart, *OutBufEnd, *OutBufCur >>>> >>>> Moreover, at runtime the two sets of pointers need to be coordinated >>>> between the SmallString and raw_svector_ostream using >>>> raw_svector_ostream::init, raw_svector_ostream::pwrite, >>>> raw_svector_ostream::re...

...; + *OutBufCur++ = C; >> + return *this; >> + } >> >> Is 3 times as fast as raw_svector_ostream? I don't see a good reason why >> that should be any faster than: >> >> raw_ostream &operator<<(char C) { >> if (OutBufCur >= OutBufEnd) >> return write(C); >> *OutBufCur++ = C; >> return *this; >> } >> >> >> You might just be seeing the difference between having write inlined vs. >> non-inlined, in which case your patch might be a complicated way to pull >> the...

...gt;> Use OS.str() >> >> While raw_svector_ostream is smart to share the text buffer itself, it's >> inefficient keeping two sets of pointers to the same buffer: >> >> In SmallString: void *BeginX, *EndX, *CapacityX >> In raw_ostream: char *OutBufStart, *OutBufEnd, *OutBufCur >> >> Moreover, at runtime the two sets of pointers need to be coordinated >> between the SmallString and raw_svector_ostream using >> raw_svector_ostream::init, raw_svector_ostream::pwrite, raw_svector_ostream::resync >> and raw_svector_ostream::write_impl...

...>>>> Is 3 times as fast as raw_svector_ostream? I don't see a good reason > >>>>> why that should be any faster than: > >>>>> > >>>>> raw_ostream &operator<<(char C) { > >>>>> if (OutBufCur >= OutBufEnd) > >>>>> return write(C); > >>>>> *OutBufCur++ = C; > >>>>> return *this; > >>>>> } > >>>>> > >>>>> > >>>>> You might just be seeing the difference between h...

...;>>> + } >>>> >>>> Is 3 times as fast as raw_svector_ostream? I don't see a good reason >>>> why that should be any faster than: >>>> >>>> raw_ostream &operator<<(char C) { >>>> if (OutBufCur >= OutBufEnd) >>>> return write(C); >>>> *OutBufCur++ = C; >>>> return *this; >>>> } >>>> >>>> >>>> You might just be seeing the difference between having write inlined >>>> vs. non-inlined, in which...

...w_svector_ostream? I don't see a good > reason > >> >>>>> why that should be any faster than: > >> >>>>> > >> >>>>> raw_ostream &operator<<(char C) { > >> >>>>> if (OutBufCur >= OutBufEnd) > >> >>>>> return write(C); > >> >>>>> *OutBufCur++ = C; > >> >>>>> return *this; > >> >>>>> } > >> >>>>> > >> >>>>> > >> >&gt...

https://bugzilla.samba.org/show_bug.cgi?id=11338 Bug ID: 11338 Summary: Rsync Crash - Segmentation fault Product: rsync Version: 3.1.1 Hardware: x64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayned at samba.org Reporter:

...l (step=0x80a2ee8, data=0x80a2fe8, inptrp=0xbfffb05c, inend=0xbfffbd48 "\n", outbufstart=0x0, irreversible=0xbfffb018, do_flush=0, consume_incomplete=0) at skeleton.c:483 #2 0xb7f99ec7 in __gconv (cd=0x80a2fe0, inbuf=0xbfffb05c, inbufend=0xbfffbd48 "\n", outbuf=0xbfffb064, outbufend=0x80a3d24 "", irreversible=0xbfffb018) at gconv.c:63 #3 0xb7f996fc in iconv (cd=0x80a2fe0, inbuf=0xbfffb05c, inbytesleft=0xbfffb060, outbuf=0xbfffb064, outbytesleft=0xbfffb068) at iconv.c:53 #4 0x08050f6d in iconvbufs (ic=0x80a2fe0, in=0xbfffb4a0, out=0xbfffb4b0, flags=0) at rsync.c:175...