On Feb 9, 2006, Daniel Jacobowitz wrote: > On Thu, Feb 09, 2006 at 10:32:48PM -0200, Alexandre Oliva wrote: >> On Feb 8, 2006, Daniel Jacobowitz wrote: >> >> > On Wed, Feb 08, 2006 at 12:48:11AM -0200, Alexandre Oliva wrote: >> >> On Jan 22, 2006, Daniel Jacobowitz wrote: >> >> >> >> > The output is always a DOUBLEST. I don't know of any reason why we >> >> > should enable HAVE_LONG_DOUBLE if we can't printf and scanf them; would >> >> > this be simpler in that case? Don't make DOUBLEST something we can't >> >> > scan or print. >> >> >> >> Sounds good to me. Ok to install? >> >> > Well, it's not right as-is; you need to look at the other uses of >> > HAVE_LONG_DOUBLE. >> >> Did. The other uses of HAVE_LONG_DOUBLE are correct, since they do >> not assume DOUBLEST is long double and they make no attempts at >> printing long doubles directly. > Disagree; did you read the bit of my message that you snipped? > doublest.c jumps through unnecessary hoops casting to long double and > back to handle a DOUBLEST if this is defined. Yep. It didn't look like those two occurrences were such a big deal. I don't see why we should refuse to handle long double at all just because we can't scan them in as such. But it's not my call, I guess. >> > Would you mind terribly fixing that, adding a changelog, and leaving >> > out the tui-data change for now? >> gdb won't build without the tui-data change. What's wrong with adding >> the temporary fix now, such that it builds, until someone with a >> better understanding can go ahead and re-engineer the data structure >> correctly? > Sorry, use -Wno-error if you're in that much of a hurry. I even > offered to take care of it for you. If your fix goes in, it will never > leave; we have plenty of experience with FIXMEs in GDB to back that up, > I think. Ok, I tried changing the type in the struct declaration and that seems to have worked, so I went ahead and removed the now-redundant type casts. Ok to install?