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
wrote:
> No, the TSMLoc should still be valid. That's the point of requiring using
> TSMLoc. Internally it does a pointer indirection so t
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 wrote:
> read, delete, etc.
> If you can share some pseudo
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 于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)
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 ha
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 于2018年9月12日周三 下午4:52写道：
> Who has used this and what issues (if any)
