Re: strncpy is not a safe version of strcpy

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: strncpy is not a safe version of strcpy
Дата
Msg-id CAApHDvp6YM9tSBCLZOrA-P5oAWjoN-dDU7200O7wERsiG=9EYA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: strncpy is not a safe version of strcpy  (Noah Misch <noah@leadboat.com>)
Ответы Re: strncpy is not a safe version of strcpy  (Kevin Grittner <kgrittn@ymail.com>)
Список pgsql-hackers
On Wed, Aug 13, 2014 at 3:19 PM, Noah Misch <noah@leadboat.com> wrote:
On Sat, Nov 16, 2013 at 12:53:10PM +1300, David Rowley wrote:
> I went on a bit of a strncpy cleanup rampage this morning and ended up
> finding quite a few places where strncpy is used wrongly.
> I'm not quite sure if I have got them all in this patch, but I' think I've
> got the obvious ones at least.
>
> For the hash_search in jsconfuncs.c after thinking about it a bit more...
> Can we not just pass the attname without making a copy of it? I see keyPtr
> in hash_search is const void * so it shouldn't get modified in there. I
> can't quite see the reason for making the copy.

+1 for the goal of this patch.  Another commit took care of your jsonfuncs.c
concerns, and the patch for CVE-2014-0065 fixed several of the others.  Plenty
remain, though.


Thanks for taking interest in this.
I had a quick look at the usages of strncpy in master tonight and I've really just picked out the obviously broken ones for now. The other ones, on first look, either look safe, or require some more analysis to see what's actually done with the string.

I think this is likely best tackled in small increments anyway. 

Does anyone disagree with the 2 changes in the attached?

Regards

David Rowley 
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal for 9.5: monitoring lock time for slow queries
Следующее
От: "Tomas Vondra"
Дата:
Сообщение: Re: 9.5: Memory-bounded HashAgg