Re: overlapping strncpy/memcpy errors via valgrind

<p dir="ltr">Peter G is sitting near me and reminded me that this issue came up in the past. Iirc the conclusion then
isthat we're calling memcpy where the source and destination pointers are sometimes identical. Tom decided there was
reallyno realistic architecture where that wouldn't work. We're not calling it on overlapping nonidentical pointers.
<divclass="gmail_quote">On Feb 17, 2013 2:22 PM, "Andres Freund" <<a
href="mailto:andres@2ndquadrant.com">andres@2ndquadrant.com</a>>wrote:<br type="attribution" /><blockquote
class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> ==24373== Source and
destinationoverlap in strncpy(0x28b892f5, 0x28b892f5, 64)<br /> ==24373==    at 0x402A8F2: strncpy
(mc_replace_strmem.c:477)<br/> ==24373==    by 0x7D563F: namestrcpy (name.c:221)<br /> ==24373==    by 0x46DF31:
TupleDescInitEntry(tupdesc.c:473)<br /> ==24373==    by 0x889EC3: resolve_polymorphic_tupdesc (funcapi.c:573)<br />
==24373==   by 0x889873: internal_get_result_type (funcapi.c:322)<br /> ==24373==    by 0x8896A2: get_expr_result_type
(funcapi.c:235)<br/> ==24373==    by 0x594577: addRangeTableEntryForFunction (parse_relation.c:1206)<br /> ==24373==  
 by0x57D81E: transformRangeFunction (parse_clause.c:550)<br /> ==24373==    by 0x57DBE1: transformFromClauseItem
(parse_clause.c:658)<br/> ==24373==    by 0x57CF01: transformFromClause (parse_clause.c:120)<br /> ==24373==    by
0x54F9A5:transformSelectStmt (analyze.c:925)<br /> ==24373==    by 0x54E4E9: transformStmt (analyze.c:242)<br /><br />
==24373==Source and destination overlap in memcpy(0x546abc0, 0x546abc0, 24)<br /> ==24373==    at 0x402B930: memcpy
(mc_replace_strmem.c:883)<br/> ==24373==    by 0x853BAB: uniqueentry (tsvector.c:127)<br /> ==24373==    by 0x8541A5:
tsvectorin(tsvector.c:262)<br /> ==24373==    by 0x888781: InputFunctionCall (fmgr.c:1916)<br /> ==24373==    by
0x888A7D:OidInputFunctionCall (fmgr.c:2047)<br /> ==24373==    by 0x59B6D7: stringTypeDatum (parse_type.c:592)<br />
==24373==   by 0x580E14: coerce_type (parse_coerce.c:303)<br /> ==24373==    by 0x580AD4: coerce_to_target_type
(parse_coerce.c:101)<br/> ==24373==    by 0x58B802: transformTypeCast (parse_expr.c:2222)<br /> ==24373==    by
0x587484:transformExprRecurse (parse_expr.c:208)<br /> ==24373==    by 0x587156: transformExpr (parse_expr.c:116)<br />
==24373==   by 0x5975CC: transformTargetEntry (parse_target.c:94)<br /><br /> I didn't check out the tsvector case but
the<br/> resolve_polymorphic_tupdesc/TupleDescInitEntry is clearly bogusly coded.<br /><br /> Do we care? strncpy'ing a
stringover itself isn't defined...<br /><br /> Greetings,<br /><br /> Andres Freund<br /><br /> --<br />  Andres Freund
                   <a href="http://www.2ndQuadrant.com/" target="_blank">http://www.2ndQuadrant.com/</a><br />
 PostgreSQLDevelopment, 24x7 Support, Training & Services<br /><br /><br /> --<br /> Sent via pgsql-hackers mailing
list(<a href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br /> To make changes to your
subscription:<br/><a href="http://www.postgresql.org/mailpref/pgsql-hackers"
target="_blank">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/></blockquote></div>