Does Windows automatically add, as a signature, an EOL when sending the first two-byte characters in the interprocess communication pipe?

Question

I have a general question about sending commands and data through Windows pipes. It seems that this problem does not happen on Unix operating systems.

This question is not specific to my application, but for illustration purposes, I will explain my problem through two examples using the gnuplot-iostream and the matplotplusplus C++ libraries.

Gnuplot-iostream

In my application, I am interacting with gnuplot through gnuplot-iostream, which is a C++ IO stream API.

In a nutshell, the gnuplot-iostream API is distributed as a simple header file, which, among others, links against the boost-iostream library to send commands and data to the gnuplot application. To do so, the API opens a pipe between the user's C++ program and gnuplot, and, through a very thin abstract layer, the user is able to send commands and data through the pipe.

When sending data to gnuplot, I've noticed that the first data point was not plotted correctly. After a very careful investigation, I've discovered that the first two characters of the data sent through the pipe were ignored.

Consider the following code snippet.

#include <vector>
#include "gnuplot-iostream.h"

std::vector<double> x = {-1.45809};
std::vector<double> y = {1.34003};
std::vector<double> z = {3.92172};

Gnuplot gp(stdout);
gp << "set view 90, 0\n";
gp << "set xlabel 'x'\n";
gp << "set ylabel 'y'\n";
gp << "set zlabel 'z'\n";
gp << "splot '-' with points\n";
gp.send1d(boost::make_tuple(x, y, z));

When plotting the above, I noticed that gnuplot received x = 0.45809, which means that "-1" has been truncated. Below is the image proof of what I have on my screen.

I think this truncation is due to the fact that Windows adds an EOL at the end of the first two characters. The next example will hopefully clarify my claim. Note that this bug has not been officially reported, but the author of gnuplot-iostream has reported several issues about the iostream for Windows users, which have not been fixed yet.

Maplotplusplus

Matplotplusplus is another API to plot graphs using C++ with an interface very similar to Python's matplotlib. This API does not use Python interpreter and communicates with gnuplot as the backend application.

I will not enter into the details, but after a thorough investigation in the source codes, it happened that there was no mistake but the console outputted the following warning messages when running a simple "hello world" plotting program.

gnuplot> se
           ^
         line 0: unrecognized option - see 'help set'.

gnuplot> t terminal wxt title "Figure 1" size 560,420 enhanced font "Sans,10"
         ^
         line 0: invalid command

To me, it becomes quite clear that Windows is adding an undesired "\n" at the end of the first two characters. The desired command sent should be: set terminal wxt title "Figure 1" size 560,420 enhanced font "Sans,10", but the "se" of "set" has been truncated. So Windows has sent: se\nt terminal wxt title "Figure 1" size 560,420 enhanced font "Sans,10" instead. By the way, I am not the only user reporting this bug.

My question is the following. Is it possible to cirucumvent this annoying problem due to Windows? Why such useless two-byte signature is sent over the pipe? An easy trick to solve this problem is to add two spaces in the string and send a dummy signature command before sending the actual data, but that is not a clean solution.

Do you have any idea in which direction I should search to solve this problem? Is it a boost library problem or a Windows problem? It seems that there is no such of a fuss using Unix operating systems, as the pipe structure is well integrated into the OS. In the case of Windows, the OS pipe structure is quite different, which can cause unreliable communication issues.

Answer 1

The output stream buffer needs to be flushed.