Re: memory-related bugs
От | Tom Lane |
---|---|
Тема | Re: memory-related bugs |
Дата | |
Msg-id | 26254.1299951869@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | memory-related bugs (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: memory-related bugs
|
Список | pgsql-hackers |
Noah Misch <noah@leadboat.com> writes: > A suitably-instrumented run of "make installcheck-world" under valgrind turned > up a handful of memory-related bugs: Hmm, interesting work, but I don't think I believe in the necessity for this kluge: > + else if (attributeName != &(att->attname)) > + namestrcpy(&(att->attname), attributeName); The rules against overlapping memcpy/strcpy's source and destination are meant to cover the case of partial overlap; I find it hard to imagine an implementation that will mess up when the source and destination are identical. If we did think it was important to avoid this situation I would rather find another way, like modifying the caller. Likewise the other changes to avoid no-op memcpy's do not appear to me to be bugs, though possibly they might save enough cycles to be worth doing anyway. > ! stats->attrtype = (Form_pg_type) palloc(sizeof(FormData_pg_type)); > ! memcpy(stats->attrtype, GETSTRUCT(typtuple), sizeof(FormData_pg_type)); > ... > ! stats->attrtype = (Form_pg_type) palloc(TYPE_FIXED_PART_SIZE); > ! memcpy(stats->attrtype, GETSTRUCT(typtuple), TYPE_FIXED_PART_SIZE); I wonder whether we should instead fix this by copying the correct tuple length. regards, tom lane
В списке pgsql-hackers по дате отправления: