Number: 26
Title: Windows version incorrectly inserts "return linefeed"s instead of linefeeds.
Submitter: Ryan Rhodes Newton
Date: Tue Jun 12 03:09:00 2001
Subsys: Dot
Version: 1.7.6 and 1.5
System: x86-Other-Windows
Severity: critical
Problem:
When running dot with output to stdout, dot will *always* print carriage-return/linefeeds, even when it is printing a *binary* image file as output.

Thus bad image files: dot test.dot -Tgif >> test.gif is equivalent to: dot test.dot -Tgif -o test.gif on Unix systems, but in windows the former breaks. (And obviously there is no way for me to fix it by simply replacing the return/linefeeds in the output with single linefeeds. The ascii characters 13 and 10 will occur next to eachother by happenstance every 65000 bytes or so.)

I wish to use dot in console mode because I am calling it as a subprocess from a program I'm writing for school, I don't want the massive slowdown of communicating through files on disk. It seems like dot was designed with this in mind, as it is extremely well suited to this usage (with the non-fancy, "pure" console interface). BUT, sadly, I can't use it in it's present state.

I presume this problem was a result of compiling it with UWIN? A global change to newlines for console interface? Is there anyway I can fix or get around this problem?

Does dot compile with Cygwin, or just UWIN? I will try to hack the source if I must, but am reluctant to attempt such.

-Ryan Newton
Input:

graph a { b }
Output file: b26.gif
Fix:
I wish I had one!

John writes: There is already code to fix this in dotneato/common/gdgen.c:183

The problem may be that HAVE_SETMODE is not being defined for the Windows build?
Owner: john
Status: Fixed