Commit 9a9473f3 authored by Tom Lane's avatar Tom Lane

Prevent using strncpy with src == dest in TupleDescInitEntry.

The C and POSIX standards state that strncpy's behavior is undefined when
source and destination areas overlap.  While it remains dubious whether any
implementations really misbehave when the pointers are exactly equal, some
platforms are now starting to force the issue by complaining when an
undefined call occurs.  (In particular OS X 10.9 has been seen to dump core
here, though the exact set of circumstances needed to trigger that remain
elusive.  Similar behavior can be expected to be optional on Linux and
other platforms in the near future.)  So tweak the code to explicitly do
nothing when nothing need be done.

Back-patch to all active branches.  In HEAD, this also lets us get rid of
an exception in valgrind.supp.

Per discussion of a report from Matthias Schmitt.
parent d2aecaea
...@@ -468,6 +468,12 @@ equalTupleDescs(TupleDesc tupdesc1, TupleDesc tupdesc2) ...@@ -468,6 +468,12 @@ equalTupleDescs(TupleDesc tupdesc1, TupleDesc tupdesc2)
* This function initializes a single attribute structure in * This function initializes a single attribute structure in
* a previously allocated tuple descriptor. * a previously allocated tuple descriptor.
* *
* If attributeName is NULL, the attname field is set to an empty string
* (this is for cases where we don't know or need a name for the field).
* Also, some callers use this function to change the datatype-related fields
* in an existing tupdesc; they pass attributeName = NameStr(att->attname)
* to indicate that the attname field shouldn't be modified.
*
* Note that attcollation is set to the default for the specified datatype. * Note that attcollation is set to the default for the specified datatype.
* If a nondefault collation is needed, insert it afterwards using * If a nondefault collation is needed, insert it afterwards using
* TupleDescInitEntryCollation. * TupleDescInitEntryCollation.
...@@ -501,12 +507,12 @@ TupleDescInitEntry(TupleDesc desc, ...@@ -501,12 +507,12 @@ TupleDescInitEntry(TupleDesc desc,
/* /*
* Note: attributeName can be NULL, because the planner doesn't always * Note: attributeName can be NULL, because the planner doesn't always
* fill in valid resname values in targetlists, particularly for resjunk * fill in valid resname values in targetlists, particularly for resjunk
* attributes. * attributes. Also, do nothing if caller wants to re-use the old attname.
*/ */
if (attributeName != NULL) if (attributeName == NULL)
namestrcpy(&(att->attname), attributeName);
else
MemSet(NameStr(att->attname), 0, NAMEDATALEN); MemSet(NameStr(att->attname), 0, NAMEDATALEN);
else if (attributeName != NameStr(att->attname))
namestrcpy(&(att->attname), attributeName);
att->attstattarget = -1; att->attstattarget = -1;
att->attcacheoff = -1; att->attcacheoff = -1;
......
...@@ -64,22 +64,6 @@ ...@@ -64,22 +64,6 @@
} }
# resolve_polymorphic_tupdesc(), a subroutine of internal_get_result_type(),
# can instigate a memcpy() call where the two pointer arguments are exactly
# equal. The behavior thereof is formally undefined, but implementations
# where it's anything other than a no-op are thought unlikely.
{
noopmemcpy_internal_get_result_type
Memcheck:Overlap
fun:*strncpy*
fun:namestrcpy
fun:TupleDescInitEntry
...
fun:internal_get_result_type
}
# gcc on ppc64 can generate a four-byte read to fetch the final "char" fields # gcc on ppc64 can generate a four-byte read to fetch the final "char" fields
# of a FormData_pg_cast. This is valid compiler behavior, because a proper # of a FormData_pg_cast. This is valid compiler behavior, because a proper
# FormData_pg_cast has trailing padding. Tuples we treat as structures omit # FormData_pg_cast has trailing padding. Tuples we treat as structures omit
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment