On Sat, Nov 20, 2010 at 6:31 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Sat, Nov 20, 2010 at 12:34 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> what about building it working backwards from the end of the buffer >>> and then memmove'ing it down to the start of the buffer? > >> I think that might be more clever than is really warranted. I get >> your point about buffer overrun, but I don't think it's that hard for >> callers to do the right thing, so I'm inclined to think that's not >> worth much in this case.
It also seems wrong that a caller might happen to know that their argument will never be more than n digits but still has to allocate a buffer large enough to hold 2^64. > > Fair enough --- it was just a passing thought. > >> I had given some thought to whether it might make sense to try to >> figure out how long the string will be before we actually start >> generating it, so that we can just start in the exactly right space >> and have to clean up afterward. But the obvious implementation seems >> like it could be more expensive than just doing the copy. > > Yeah. You certainly don't want to do the division sequence twice, > and a log() call wouldn't be cheap either, and there don't seem to > be many other alternatives. There are bittwiddling hacks for computing log based 2. I'm not sure it's worth worrying about to this degree though. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
