Re: [xml] final output filtering?

[Igor Zlatkovic <igor zlatkovic com>]

Hi Peter, all,

The line-end processing in the MS C-runtime is broken. You write a file 
in text mode and the C-runtime will simply assume everything that comes 
from the C code is unix-style \n. It will convert *every* occurence of 
\n to \r\n. It will even convert proper \r\n sequences to \r\r\n.

We had this problem before. All one had to do is xmlParseFile and then 
xmlSaveFile several times using the same file, without modifying the 
DOM. One ended up with a different DOM at each xmlParseFile, the 
difference being in the line-end nodes which were getting bigger and bigger.

This problem will occur again anytime, if libxml tries to save anything 
that doesn't have strict unix-style line ends (\n).

> First, if you really want to enforce byte-by-byte identical output when 
> streaming out the tree, the writer's fopen has to be changed to:
>
> #if defined(WIN32) || defined (__CYGWIN__)
>       fd = fopen(path, "wb");
> #else
>         fd = fopen(path, "w");
> #endif /* WIN32 */

Yes, that is exactly the way it should be. I am now tempted to change 
the code so it does exactly the above. The current state makes sense 
only if the data being saved through fwrite will never, I mean never, 
contain a carriage return character.

> Then you will see, whether the Win32 users are still happy. I'm fine with 
> this, but it would limit the choice of text editors you can use.

Not by much, Notepad is about the only editor which has a problem with 
non-native line ends.

Ciao,
Igor