| From: | "anarazel(at)anarazel(dot)de" <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: overlapping strncpy/memcpy errors via valgrind |
| Date: | 2013-02-17 18:48:53 |
| Message-ID: | 3f051456-b28a-4dd1-9044-65c7feda392c@email.android.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> schrieb:
>Andres Freund <andres(at)2ndquadrant(dot)com> writes:
>> On 2013-02-17 15:10:35 +0000, Greg Stark wrote:
>>> Peter G is sitting near me and reminded me that this issue came up
>in the
>>> past. Iirc the conclusion then is that we're calling memcpy where
>the
>>> source and destination pointers are sometimes identical. Tom decided
>there
>>> was really no realistic architecture where that wouldn't work.
>
>> I am not so convinced that that is safe if libc turns that into some
>> optimized string instructions or even PCMPSTR...
>
>What would you envision happening that would be bad?
Afair some of the optimized instructions (like movdqa) don't necessarily work if source an target are in the same location. Not sure about it bit I wouldn't want to depend on it.
Andres
---
Please excuse brevity and formatting - I am writing this on my mobile phone.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | anarazel@anarazel.de | 2013-02-17 18:52:46 | Re: overlapping strncpy/memcpy errors via valgrind |
| Previous Message | David E. Wheeler | 2013-02-17 18:19:31 | Re: JSON Function Bike Shedding |