Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64
От | Dave Page |
---|---|
Тема | Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64 |
Дата | |
Msg-id | BANLkTik1Em8=mxVfw2db2VO6ejxbjf1NKA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64
|
Список | pgsql-committers |
On Thu, Apr 28, 2011 at 8:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Dave Page <dpage@postgresql.org> writes: >> On Thu, Apr 28, 2011 at 6:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Dave, can you poke at this? > >> I think we may have to award Sun (or whats left of them) the "Bizarre >> compiler bug of the week" award here. > > Yeah. Has anyone filed a report with them? I haven't. Oracle dont seem to make it easy to do such things (at least for those of us without support contracts). >> It's actually the val++; that's >> causing the assertion, but I'm darned if I can get it to work. I've >> tried spelling out the addition, casting, changing val to an int64*, >> renaming val, and probably a dozen or so things that are broken, all >> with no success. >> Any other ideas? > > I was suspicious that it had something to do with the compiler trying to > optimize the size / mult and size % mult subexpressions to get both > results with one division instruction. Can you check if removing either > of those makes the crash go away? Already did (that was my first assumption). Removing them doesn't help, nor does rewriting them in various strange ways. Removing val++; (and replacing with { } ) allows compilation to succeed. I guess the best bet is a compiler update, if I can persuade the oracle website to let me download it... -- Dave Page PostgreSQL Core Team http://www.postgresql.org/
В списке pgsql-committers по дате отправления: