There is a bug in the stdio library for old Sun operating systems (SunOS
Sys4-3.2). The "%g" format for 'printf' sometimes incorrectly prints numbers
(e.g., 200000.0 as "2"). Thus, tic mark labels may be incorrect on a Sun4
version of gnuplot. A work-around is to rescale the data or use the `set
format` command to change the tic mark format to "%7.0f" or some other
appropriate format. This appears to have been fixed in SunOS 4.0.
Another bug: On a Sun3 under SunOS 4.0, and on Sun4's under Sys4-3.2 and SunOS 4.0, the 'sscanf' routine incorrectly parses "00 12" with the format "%f %f" and reads 0 and 0 instead of 0 and 12. This affects data input. If the data file contains x coordinates that are zero but are specified like '00', '000', etc, then you will read the wrong y values. Check any data files or upgrade the SunOS. It appears to have been fixed in SunOS 4.1.1.
Suns appear to overflow when calculating exp(-x) for large x, so gnuplot
gets an undefined result. One work-around is to make a user-defined function
like e(x) = x<-500 ? 0 : exp(x). This affects plots of Gaussians (exp(-x*x))
in particular, since x*x grows quite rapidly.
Microsoft C 5.1 has a nasty bug associated with the %g format for 'printf'. When any of the formats "%.2g", "%.1g", "%.0g", "%.g" are used, 'printf' will incorrectly print numbers in the range 1e-4 to 1e-1. Numbers that should be printed in the %e format are incorrectly printed in the %f format, with the wrong number of zeros after the decimal point. To work around this problem, use the %e or %f formats explicitly.
gnuplot, when compiled with Microsoft C, did not work correctly on two VGA
displays that were tested. The CGA, EGA and VGA drivers should probably be
rewritten to use the Microsoft C graphics library. gnuplot compiled with
Borland C++ uses the Turbo C graphics drivers and does work correctly with
VGA displays.
VAX/VMS 4.7 C compiler release 2.4 also has a poorly implemented %g format for 'printf'. The numbers are printed numerically correct, but may not be in the requested format. The K&R second edition says that for the %g format, %e is used if the exponent is less than -4 or greater than or equal to the precision. The VAX uses %e format if the exponent is less than -1. The VAX appears to take no notice of the precision when deciding whether to use %e or %f for numbers less than 1. To work around this problem, use the %e or %f formats explicitly. From the VAX C 2.4 release notes: e,E,f,F,g,G Result will always contain a decimal point. For g and G, trailing zeros will not be removed from the result.
VAX/VMS 5.2 C compiler release 3.0 has a slightly better implemented %g format than release 2.4, but not much. Trailing decimal points are now removed, but trailing zeros are still not removed from %g numbers in exponential format.
The two preceding problems are actually in the libraries rather than in the
compilers. Thus the problems will occur whether gnuplot is built using
either the DEC compiler or some other one (e.g. the latest gcc).
ULTRIX X11R3 has a bug that causes the X11 driver to display "every other" graph. The bug seems to be fixed in DEC's release of X11R4 so newer releases of ULTRIX don't seem to have the problem. Solutions for older sites include upgrading the X11 libraries (from DEC or direct from MIT) or defining ULTRIX_KLUDGE when compiling the x11.trm file. Note that the kludge is not an ideal fix, however.
The constant HUGE was incorrectly defined in the NeXT OS 2.0 operating system. HUGE should be set to 1e38 in plot.h. This error has been corrected in the 2.1 version of NeXT OS.
Some older models of HP plotters do not have a page eject command 'PG'. The current HPGL driver uses this command in HPGL_reset. This may need to be removed for these plotters. The current PCL5 driver uses HPGL/2 for text as well as graphics. This should be modified to use scalable PCL fonts.
On the Atari version, it is not possible to send output directly to the
printer (using /dev/lp as output file), since CRs are added to LFs in
binary output. As a work-around, write the output to a file and copy it to
the printer afterwards using a shell command.
On AIX 4, the literal 'NaNq' in a datafile causes the special internal value
'not-a-number' to be stored, rather than setting an internal 'undefined'
flag. A workaround is to use set missing 'NaNq'.
There may be an up-to-date list of bugs since the release on the WWW page:
http://www.cs.dartmouth.edu/gnuplot_info.html
Please report any bugs to bug-gnuplot@dartmouth.edu.