|
From: Ethan M. <merritt@u.washington.edu> - 2008-05-16 22:23:30
|
On Friday 16 May 2008 15:07, Lutz Maibaum wrote: > Hi Ethan, > > > The zoom function reads off (x1,y1) and (x2,y2) coords from the mouse > > and constructs the appropriate "set [xy]range" commands as a string > > which is fed back to the command line interpreter. In your case the > > lower bound on y is too large to represent as an integer. This would > > normally be OK because it is written using a floating point format > > > > mouse.c line 662: sprintf(s, "set xr[%.12g:%.12g]; set > > yr[%.12g:%.12g]" > > > > but since there is nothing after the decimal point, the %g format writes > > it as a 12 digit integer. Such an integer is too large to read in. It > > would work if there were a trailing decimal point, but there isn't one. > > thanks for looking into this. I must admit I don't quite understand your > proposed changes to the scanner, but as a quick fix would it be sufficient > to replace the %g in the line above by %E, which always includes a decimal > point? That would probably fix it for the specific case of zooming, but the general case would still be broken. As it stands, all integer constants in the input stream are silently truncated to LONG_MAX on a "normal" machine configuration. Yours at least prints an error message. -- Ethan A Merritt |