Corrupt output of printf

Corrupt output of printf

[Dawid Toton]

I have a program, which output is produced only with Printf.printf .
This inner part is executed by another one (outer) using Unix.system . 
The outer executable uses print_endline before and after the inner is run.

 From time to time the output of the inner program is corrupt.

Printf.printf seemingly devours parts of single lines, as in these 
examples (all lines should have the same structure):

156 In: 5.483000, 1.500000, 1.760000
157 Sb: 5.008000, 1.494000, 1.500000
158 In: 4.498000, 1.494000, 0.750000
159160 Sb: 5.003000, 1.503000, 0.508000

Another one:

138 In: 5.000000, 0.000000, 0.253000
139 In: 5.001000, 1.000140 Sb: 5.500000, 0.000000, 0.000000
141 Sb: 5.500000, 1.000000, 0.000000

This isn't easily reproducible as it happens rarely; subsequent runs are OK.

Could anybody find a possible cause of this behavior?

Dawid

Re: [Caml-list] (Not) corrupt output of printf

[Dawid Toton]

This was actually a bug in GNOME Terminal... sorry for the noise.

Dawid

Re: [Caml-list] (Not) corrupt output of printf

[Richard Jones]

On Fri, Jan 23, 2009 at 11:20:35AM +0000, Dawid Toton wrote:
> This was actually a bug in GNOME Terminal... sorry for the noise.

Weird ... I was going to suggeest it was because you weren't flushing
the output after each print statement.  I usually do:

  printf "something\n%!"

(the %! forces a flush of the output channel).

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] (Not) corrupt output of printf

[Dawid Toton]

> Weird ... I was going to suggeest it was because you weren't flushing
> the output after each print statement.  

This raises important question:
Let's see the output as a sequence of bytes (there's no time).
Assuming that the process exits normally and incompatible printing 
functions are not mixed:
is there a guarantee (in OCaml library) that the flush operation doesn't 
affect the output?

For me it's obvious that the output shouldn't depend on the presence of 
flush operations. If otherwise - needs to be explicitly stated.

(Of course I'm not considering the one special flush action done when 
closing a stream, but it's tied to the closing function.)

Dawid

Re: [Caml-list] (Not) corrupt output of printf

[Eric Cooper]

On Fri, Jan 23, 2009 at 02:20:41PM +0000, Dawid Toton wrote:
> Let's see the output as a sequence of bytes (there's no time).
> Assuming that the process exits normally and incompatible printing  
> functions are not mixed:
> is there a guarantee (in OCaml library) that the flush operation doesn't  
> affect the output?

The flush operation only relates to the time at which the write
occurs (i.e., flush may make it occur sooner than it would otherwise).
So if you're ignoring the time element (and error cases like writing
to a full disk or a broken pipe), it's unobservable.

But if the output is part of a larger interactive system -- prompting
a user for input, or engaging in a 2-way protocol with another process
-- then flushing can be essential for correct behavior.

-- 
Eric Cooper             e c c @ c m u . e d u