Обсуждение: Memory error in src/backend/replication/logical/origin.c

Hackers,
       bool        nulls[Natts_pg_replication_origin];
...           memset(&nulls, 0, sizeof(nulls));

around lines 277 through 303.  Patch below.

mark



diff --git a/src/backend/replication/logical/origin.c b/src/backend/replication/logical/origin.c
index 55382b4b24..88188bd190 100644
--- a/src/backend/replication/logical/origin.c
+++ b/src/backend/replication/logical/origin.c
@@ -300,7 +300,7 @@ replorigin_create(char *roname)                        * Ok, found an unused roident, insert the
newrow and do a CCI,                        * so our callers can look it up if they want to.                        */ 
-                       memset(&nulls, 0, sizeof(nulls));
+                       memset(nulls, 0, sizeof(nulls));
values[Anum_pg_replication_origin_roident- 1] = ObjectIdGetDatum(roident);
values[Anum_pg_replication_origin_roname- 1] = roname_d; 

Mark Dilger <hornschnorter@gmail.com> writes:
>         bool        nulls[Natts_pg_replication_origin];
>             memset(&nulls, 0, sizeof(nulls));

> around lines 277 through 303.  Patch below.

AFAIK this is not a bug, though I agree that dropping the "&" is probably
better style.  The reason is that applying "&" to an undecorated array
name is basically a no-op, because without "&" the array name would decay
to a pointer anyway.  With "&", the address-taking is explicit, but you
still get a pointer to the array, not a pointer to some pointer to the
array.  Ain't C fun?
        regards, tom lane

> On Nov 26, 2017, at 10:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> Mark Dilger <hornschnorter@gmail.com> writes:
>>        bool        nulls[Natts_pg_replication_origin];
>>            memset(&nulls, 0, sizeof(nulls));
> 
>> around lines 277 through 303.  Patch below.
> 
> AFAIK this is not a bug, though I agree that dropping the "&" is probably
> better style.  The reason is that applying "&" to an undecorated array
> name is basically a no-op, because without "&" the array name would decay
> to a pointer anyway.  With "&", the address-taking is explicit, but you
> still get a pointer to the array, not a pointer to some pointer to the
> array.  Ain't C fun?

Thanks for the refresher on C madness.

mark