Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
| От | Nigel J. Andrews |
|---|---|
| Тема | Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in |
| Дата | |
| Msg-id | Pine.LNX.4.21.0208201539200.1042-100000@ponder.fairway2k.co.uk обсуждение исходный текст |
| Ответ на | Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in |
| Список | pgsql-hackers |
On Tue, 20 Aug 2002, Tom Lane wrote: > "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes: > >> I'd like to see something done about this fairly soon, but it's not > >> happening for 7.3 ... > > > Does anyone have an idea about what other functions are affected by this? > > As a first approximation, every output function for a built-in > pass-by-reference datatype will show this same behavior. cash_out is > just getting picked on because it was the one mentioned in the first > complaint. For that matter, every input function for any datatype > has the same problem: > regression=# select cash_in(2); > server closed the connection unexpectedly > > ... But going back to the idea that it seems that the only problem being publicised in the 'outside world' is the cash_out(2) version can we not do the restriction on acceptable input type in order to claim that the fix? Obviously this is only a marketing ploy but on the basis that a real fix seems unlikely before beta in 11 days time (I'm still trying to work out what Tom's suggestion is) perhaps one worth implementing. -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants
В списке pgsql-hackers по дате отправления: