I don't understand. What does "pointer from a TSMLoc" mean? How can the TSMLoc still be valid but not be safe?
On Mon, Sep 17, 2018 at 2:35 PM, Alan Carroll <solidwallofc...@oath.com.invalid> wrote: > No, the TSMLoc should still be valid. That's the point of requiring using > TSMLoc. Internally it does a pointer indirection so the pointer can > updated. What's not safe is any pointer from a TSMLoc. > > On Thu, Sep 13, 2018 at 8:48 PM CrazyCow <zhangzizhong0...@gmail.com> wrote: > >> read, delete, etc. >> If you can share some pseudo code having the issue, we can analyze it to >> see if it's a design issue or being used in a wrong way. >> >> Walt Karas <wka...@oath.com.invalid> 于2018年9月13日周四 上午8:21写道： >> >> > Do you use it to change the contents of headers or just to read them? >> > >> > I've been told that if (for example) you get the TSMLoc for two >> > header fields, and then change or delete the second field, this may >> > cause the first TSMLoc to become a dangling pointer. It doesn't look >> > like the Header.h code handles this possibility. >> > >> > On Wed, Sep 12, 2018 at 7:55 PM, zzz <z...@apache.org> wrote: >> > > Linkedin Traffic team is actively using it. It's quite handy. >> > > (Thanks @bgeffon >> > > One issue we found so far is Headers.wireStr() is much slower than the >> > raw >> > > API equivalent TSMimeHdrPrint, so you've better to avoid that. >> > > >> > > Walt Karas <wka...@oath.com.invalid> 于2018年9月12日周三 下午4:52写道： >> > > >> > >> Who has used this and what issues (if any) have you had with it? >> > >> >> > >> > > > -- > *Beware the fisherman who's casting out his line in to a dried up riverbed.* > *Oh don't try to tell him 'cause he won't believe. Throw some bread to the > ducks instead.* > *It's easier that way. *- Genesis : Duke : VI 25-28
