Re: Buffer overflow in psql

Поиск
Список
Период
Сортировка
Искать
От
John D. Burger
Тема
Re: Buffer overflow in psql
Дата
Msg-id
8CB0E733-D4C0-431F-AD37-EBE6FD2CC8FE@mitre.org
Ответ на
Список
Дерево обсуждения
Buffer overflow in psql Jack Orenstein <jorenstein@archivas.com>
Re: Buffer overflow in psql Martijn van Oosterhout <kleptog@svana.org>
Re: Buffer overflow in psql Tom Lane <tgl@sss.pgh.pa.us>
Re: Buffer overflow in psql Jack Orenstein <jorenstein@archivas.com>
Re: Buffer overflow in psql Tom Lane <tgl@sss.pgh.pa.us>
Re: Buffer overflow in psql "John D. Burger" <john@mitre.org>
Re: Buffer overflow in psql Tom Lane <tgl@sss.pgh.pa.us>
Re: Buffer overflow in psql "John D. Burger" <john@mitre.org>
Tom Lane wrote:

> Ah so, that explains how come it noticed.  BTW, I see that somebody
> already changed the array size to 16 bytes in HEAD --- so it's just
> the back branches that need fixing.

Um, is that really considered a fix???  We all know that there's no  
guarantee at all, even in ANSI C, that unsigned int isn't bigger than  
32 bits, right?  There are still some weird architectures out there.

Whenever I need to print some integer x, I use code like this:

   char buf[1 + sizeof(x) * CHAR_BIT / 3]

I let the compiler figure out the length needed to print in octal,  
and use that as a (slight) over-estimate of the length for decimal.   
As a bonus, the type of x can be changed without having to track down  
this kind of crap.

Alternatively, the code in question could just cast to one of the  
newer fixed-length int types, like int32_t, although that has its own  
problems.

Sorry for the pedantry ...

- John D. Burger
   MITRE

В списке pgsql-general по дате отправления
От: Adrian Klaver
Дата:
Сообщение: Re: Data
От: Tom Lane
Дата:
Сообщение: Re: Buffer overflow in psql
FAQ