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
