Re: @(#)Mordred Labs advisory 0x0004: Multiple buffer - Mailing list pgsql-hackers

From Vince Vielhaber
Subject Re: @(#)Mordred Labs advisory 0x0004: Multiple buffer
Date
Msg-id Pine.BSF.4.40.0208201718450.19197-100000@paprika.michvhf.com
Whole thread Raw
In response to Re: @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)  (Neil Conway <neilc@samurai.com>)
Responses Re: @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)  (Neil Conway <neilc@samurai.com>)
Re: @(#)Mordred Labs advisory 0x0004: Multiple buffer  (Tatsuo Ishii <t-ishii@sra.co.jp>)
List pgsql-hackers
On 20 Aug 2002, Neil Conway wrote:

> Vince Vielhaber <vev@michvhf.com> writes:
> > And another one.
>
> This patch should fix the problem. Doesn't include my previous patch
> for repeat(). Again, somewhat off-the-cuff, so I might have missed
> something...
>
> test=# select lpad('xxxxx',1431655765,'yyyyyyyyyyyyyyyy');
> ERROR:  Requested length too large
> test=# select rpad('xxxxx',1431655765,'yyyyyyyyyyyyyyyy');
> ERROR:  Requested length too large
>
> (That's on a Unicode DB, haven't tested other encodings but AFAICT
> this fix should still work.)

Is there any chance that pg_database_encoding_max_length() could return
zero and give a divide by zero error?  Or is that trapped?

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking     http://www.camping-usa.com      http://www.cloudninegifts.com  http://www.meanstreamradio.com
 http://www.unknown-artists.com
 
==========================================================================





pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: SQL99 CONVERT() function
Next
From: Oliver Elphick
Date:
Subject: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in