Is there a library routine like fgets() but which takes any of CR, NL, and CR+NL as an end of line?

I'm pretty sure there isn't. Is using sscanf out of the question? You may be able to construct a format string that does what you want unless you really do want a CR by itself to also represent a linefeed (which I can't think how to do using sscanf). James

On Thu, 31 May 2012, James Harper <james.harper@bendigoit.com.au> wrote:

...

...

Is there a library routine like fgets() but which takes any of CR, NL, and CR+NL as an end of line?

I'm pretty sure there isn't. Is using sscanf out of the question? You may be able to construct a format string that does what you want unless you really do want a CR by itself to also represent a linefeed (which I can't think how to do using sscanf).

I really need to support either.

I'm dealing with the output of a Windows program that seems to convert between DOS and Unix file formats.

Is each file self-consistent in what it uses though? Or could it switch between CR, LF, and CR+LF as EOLs? If so, is CR+LF+LF+CR+LF 3, 4, or 5 EOLs? James

James Harper <james.harper@bendigoit.com.au> wrote:

...

Is there a library routine like fgets() but which takes any of CR, NL, and CR+NL as an end of line?

I'm pretty sure there isn't. Is using sscanf out of the question? You may be able to construct a format string that does what you want unless you really do want a CR by itself to also represent a linefeed (which I can't think how to do using sscanf).

You could write a function to do this without much trouble though. CR alone is the real problem here: if you were only concerned with LF or CR+LF then all you would have to do is deal with the case in which there's an extraneous CR at the end of the buffer (you could simply change it to '\0', I suppose, and ensure that the buffer is long enough for the expected lines, including trailing CR).

Russell Coker wrote:

On Thu, 31 May 2012, James Harper <james.harper@bendigoit.com.au> wrote:

...

...

Is there a library routine like fgets() but which takes any of CR, NL, and CR+NL as an end of line?

I'm pretty sure there isn't. Is using sscanf out of the question? You may be able to construct a format string that does what you want unless you really do want a CR by itself to also represent a linefeed (which I can't think how to do using sscanf).

I really need to support either.

I'm dealing with the output of a Windows program that seems to convert between DOS and Unix file formats.

Put something like tr or sed s/\r$// in front of your real program, and let it deal with unfucking CRLF files.

Russell Coker <russell@coker.com.au> wrote:

Below is my rough analog to fgets() which takes either \r or \n as the end of a line. It works because I don't mind getting the occasional empty line in the middle of the file, programs which can't handle extra empty lines won't work with this.

It seems correct to me. Of course, being written by Russell, one can expect it to be correct.

On Thu, 31 May 2012, Jason White <jason@jasonjgw.net> wrote:

...

You could write a function to do this without much trouble though.

Below is my rough analog to fgets() which takes either \r or \n as the end of a line. It works because I don't mind getting the occasional empty line in the middle of the file, programs which can't handle extra empty lines won't work with this.

int get_line(char *buf, int buf_len, FILE *fp) { int c, i = 0; while((c = fgetc(fp)) != EOF) { if(c == '\r' || c == '\n') { buf[i] = 0; return 1; } buf[i] = (char)c; i++; if(i == buf_len - 1) { buf[i] = 0; return 1; }

If you pass buf_len=0 or buf_len=1 you would get yourself a buffer overflow. Maybe that doesn't really matter in your case if you use hardcoded inputs, but I'd still check for it to save from puzzling crashes if you re-use the code in future. James