The most important known bug is actually in the stdio library for the Sun4 operating system (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. You may work around it by rescaling your data or by using 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 your data file contains X coordinates that are zero but are specified like '00', '000', etc, then you will read the wrong Y values. Check your data files or do not use a Sun4 until they fix the bug. It does NOT appear that this has been fixed in SunOS 4.0.
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 Turbo 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.