2010/1/18 Robert Haas <robertmh...@gmail.com>: > On Mon, Jan 18, 2010 at 1:52 PM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: >> 2010/1/18 Robert Haas <robertmh...@gmail.com>: >>> On Sun, Jan 17, 2010 at 2:04 PM, Pavel Stehule <pavel.steh...@gmail.com> >>> wrote: >>>> I rewrote patch so now interface for PQescapeIdentConn is same as >>>> PQescapeStringConn >>>> >>>> @3. I though so the protection under incomplete multibyte chars are >>>> enought - missing bytes are replaced by space - like >>>> PQescapeStringConn does. >>> >>> That much is fine, but the output buffer is only guaranteed to be of >>> size 2n+1. Imagine the input is two double-quotes followed by a byte >>> for which pg_encoding_mblen() returns 4. The input is 3 characters >>> long so the user was responsible to provide 7 bytes of output space, >>> but you'll try to write 9 bytes to it (including the terminating NUL). >>> >> I don't understand. The "length" is number of bytes, not number of >> chars. It is maybe bad documented only. If your input string has 6 >> bytes, then buffer have to allocated to 13 bytes. Nobody knows how >> much is chars there. > > Right, but the point is we can't assume that the input is validly > encoded. If the input ends with a garbage character that looks like > the start of a multi-byte character, we can't assume that there's > enough space in the output buffer to store the required number of > padding spaces. > > To take an extreme example, suppose there were an encoding where any > time the first byte of a multi-byte character has the high-bit set, > the character is 100 bytes long. Then suppose someone call > PQescapeStringConn(), or this new function we're adding, with a length > argument of 1, and the first byte of the input buffer has the high-bit > set. The caller is only required to provide a 3-byte output buffer, > and the third byte is needed for the terminating NUL. That means that > after we copy that first character we only have room to insert one > padding space. The way you had it coded, since we were expecting a > character 100 bytes long, we'd always try to insert 99 padding spaces. >
do you speak about previous version? in current version is garanted new length is <= 2x original length Pavel > >> Let me take a crack at this and post a patch. We're making this >>> harder than it needs to be. >> >> sure, please. > > Working on it... > > ...Robert > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers