[MPlayer-dev-eng] Small changes to subreader.c file

Adam Tlałka atlka at pg.gda.pl
Thu Oct 13 07:55:38 CEST 2005


Dnia Thu, 13 Oct 2005 01:07:45 +0200, Rich Felker <dalias at aerifal.cx>  
napisał:

> On Wed, Oct 12, 2005 at 10:47:53AM +0300, Ivan Kalvachev wrote:
>> I'm gonna wait few days in case original author speaks up.
>> Then I am gonna recommit the CRLF patch (with "wb" change).
>> If some of the developers are against this I would like to hear their  
>> reasoning.
>
> I am absolutely against generating windows format-only files on unix.

First of all there is no special treatment of files containing text data
on Unix. The open() C function has no special text mode, in the fopen()
one we can specify "b" binary mode for compatibility reasons with ANSI C
norm but this doesn't change the behaviour on Posix systems.
It just has no effect.
So on Unix the file is treated always the same way from system point of  
view.
So what is in it is up to you - producer of data.
I can't find a strict text file definition which forbides me
using CR, LF, or CRLF as line ending. So all this formats should be
read properly and this is accomplished in MPlayer.

But talking abut write format I can't see any reason for not outputing
CRLF type of files at all. If this type of line deliminator is the most
compatible for a some kind of subtitle text format then we should use it.

Look at what the Unix "file" utility says for some text files:

ASCII text
ASCII text, with CRLF line terminators
ISO-8859 text
ISO-8859 text, with CRLF line terminators
Non-ISO extended-ASCII text
Non-ISO extended-ASCII text, with CRLF line terminators
UTF-8 Unicode text
UTF-8 Unicode text, with CRLF line terminators

All of them are text files and there is no rule
which forbids to use CRLF in text files on Unix.
So statement that a text file on Unix is LF only is not proved.
There are most of them in this format on this system because it was coded
this way from the first time with particular utilities.
So in my logic it is just original format as it first appeared.
Some of subtitle formats appeared as CRLF text files and for many reasons
should stay in their original format. That is my point.
Adding an option could make additional mess and incompatibility.

> the text format, with default being the OS native format. Anything

There is no default text file format as we talking about line endings here.
There is no text or binary files from the system point of view on Unix.
All are the same in filesystem usage.  The definition of text files
as containing some particular data leads us to equal rights of CR, LF
or CRLF form. So only compatibility can be chosed as the reason of
outputting with particular line ending. Original format criterium
meets this.

> that unconditionally generates CRLF will be reversed by me as long as
> I have cvs access. If Attila or anyone else feels this is sufficiently
> important to kick me off the team, go right ahead.
Sorry to hear that. It is your choice as I previously said.

Regards
-- 
Adam Tlałka      mailto:atlka at pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdańsk University of Technology, Poland
PGP public key:   finger atlka at sunrise.pg.gda.pl




More information about the MPlayer-dev-eng mailing list