Re: B-Tree support function number 3 (strxfrm() optimization) - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: B-Tree support function number 3 (strxfrm() optimization)
Date
Msg-id CAM3SWZQvzY4RjqztCvnVKxxg4E26_Gy55BTqVEEUNUpi4jfS-g@mail.gmail.com
Whole thread Raw
In response to Re: B-Tree support function number 3 (strxfrm() optimization)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: B-Tree support function number 3 (strxfrm() optimization)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Mar 31, 2014 at 8:08 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> Note the last sentence. To avoid the undefined behavior, you have to pass a
> buffer that's large enough to hold the whole result, and then truncate the
> result.

I was working off the glibc documentation, which says:

"The return value is the length of the entire transformed string. This
value is not affected by the value of size, but if it is greater or
equal than size, it means that the transformed string did not entirely
fit in the array to. In this case, only as much of the string as
actually fits was stored. To get the whole transformed string, call
strxfrm again with a bigger output array."

It looks like this may be a glibc-ism. I'm not sure whether or not
it's worth attempting to benefit from glibc's apparent additional
guarantees here. Obviously that is something that would have to be
judged by weighing any actual additional benefit. FWIW, I didn't
actually imagine that this was a trick I was exploiting. I wouldn't be
surprised if this wasn't very important in practice.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Still something fishy in the fastpath lock stuff
Next
From: Alexander Korotkov
Date:
Subject: Re: Cube extension kNN support