Carriage return

[haramkhor]

Can anyone please help!!!!!!
I want to develope a program which should count lines of code.
for that I want to know what is carriage return value in C.
So please reply me as soon as possible.If possible send me the code also.
Thank you.

[AdrianH]

Can anyone please help!!!!!!
I want to develope a program which should count lines of code.
for that I want to know what is carriage return value in C.
So please reply me as soon as possible.If possible send me the code also.
Thank you.

The carriage return value is '\r', the line feed value is '\n'. The single quotes are used to get the character value of the character inside it. I.e. 'A' is 65.

We will not be giving you any code here. If you need help, try out the problem yourself and if you are still having difficulty with it, post the relivant code with a description as to what the problem you are having is.

Good luck,


Adrian

P.S. Do not double post. Thank you. See the posting guidelines here

[weaknessforcats]

\r is carriage return
\n is carriage return + newline feed

Probably you want \n.

[AdrianH]

\r is carriage return
\n is carriage return + newline feed

Probably you want \n.

If you want to get technical, in reading from/writing to a text file you are correct... under Windoze. It is not portable though.

Different operating systems define it differently. IIRC, Unix defines \n as carriage return only, Mac defines it as line feed + carriage return (reverse of Windows), other OSs I haven't a clue. I no longer work with text files anymore because of this portability issue, unless I am sure that the file generated will never be shifted to another OS or I don't care ;).


Adrian

[weaknessforcats]

Different operating systems define it differently. IIRC, Unix defines \n as carriage return only, Mac defines it as line feed + carriage return (reverse of Windows), other OSs I haven't a clue. I no longer work with text files anymore because of this portability issue, unless I am sure that the file generated will never be shifted to another OS or I don't care.

Good point.

[Banfa]

\r is carriage return
\n is carriage return + newline feed

Probably you want \n.

\n is never carriage return + newline feed, the C standard states that for a file opened in text mode the end of line marker should be trabnslated to \n. For windows this is carriage return + newline feed.

However if you put \n in a string then that string will contain a newline character with no extra characters.

The clarification I am making is that the translation is part of the file handling and nothing to do with characters and strings.

[Banfa]

I no longer work with text files anymore because of this portability issue

That's interesting because portability freaks (not that I am one) normally claim that text is the only truly portable way of transferring data between systems, hence(or at least partly hence) XML has come into being.

[AdrianH]

That's interesting because portability freaks (not that I am one) normally claim that text is the only truly portable way of transferring data between systems, hence(or at least partly hence) XML has come into being.

You are only partly right. If I generate a text file on a Mac and then copy the file over to a PC without the proper translation software, i.e. a binary copy not a text one, this will fail to be read correctly on the PC.

It really starts to get messy when using cygwin using a Unix eol sequence.

I really hate the non-standerdised end of line character sequences. :(


Adrian

[AdrianH]

\n is never carriage return + newline feed, the C standard states that for a file opened in text mode the end of line marker should be trabnslated to \n. For windows this is carriage return + newline feed.

However if you put \n in a string then that string will contain a newline character with no extra characters.

The clarification I am making is that the translation is part of the file handling and nothing to do with characters and strings.

True, but if you are processing the input stream, you have to be aware of it.


Adrian

[Banfa]

True, but if you are processing the input stream, you have to be aware of it.

True, I have to say I almost never open a file for input in text mode, I prefer to just handle the possibility of varying line end characters which you have to handle anyway if want the possibility of reading files that may have originated from any platform.

[JosAH]

Java implements a nice utility class: System. It has a member which basically
is a map<string, string>. It stores all sorts of handy little system dependent
values; one of them is "line.separator" and its value is one of \n, \r\n, \n\r or
whatever. I stole the idea and I carry such a map around, one per platform.
The map is read in memory at startup of my code and I never have to worry
about those dependencies anymore in my C++ code.

kind regards,

Jos

[AdrianH]

Java implements a nice utility class: System. It has a member which basically
is a map<string, string>. It stores all sorts of handy little system dependent
values; one of them is "line.separator" and its value is one of \n, \r\n, \n\r or
whatever. I stole the idea and I carry such a map around, one per platform.
The map is read in memory at startup of my code and I never have to worry
about those dependencies anymore in my C++ code.

kind regards,

Jos

Does it work in the case that I describe above? I.e. You are on a PC platform running your app that reads in a text file. That text file was generated on a Mac platform and was binary copied to the PC platform. Will your app recognise the Mac eol anyway?

Personally, I use scanf a lot using a format string something like: "%[^\r\n]" (with a buffer limit stated between the % and the [ of course) to read in a line and then "%*[\r\n]" to flush out the end of line characters.

When I output the chars, I either open it up as a text file and use '\n' or open it up as a binary and use a macro to output the correct EOL symbol(s) for the platform. In the cases that I don't care if it is compatiable for the local platform, I just use '\n' in a binary format. In the cases that I do care, and don't care about it's compatiblility on another platform, I use the appropriate local representation.


Adrian

[JosAH]

Does it work in the case that I describe above? I.e. You are on a PC platform running your app that reads in a text file. That text file was generated on a Mac platform and was binary copied to the PC platform. Will your app recognise the Mac eol anyway?

Personally, I use scanf a lot using a format string something like: "%[^\r\n]" (with a buffer limit stated between the % and the [ of course) to read in a line and then "%*[\r\n]" to flush out the end of line characters.

When I output the chars, I either open it up as a text file and use '\n' or open it up as a binary and use a macro to output the correct EOL symbol(s) for the platform. In the cases that I don't care if it is compatiable for the local platform, I just use '\n' in a binary format. In the cases that I do care, and don't care about it's compatiblility on another platform, I use the appropriate local representation.


Adrian

I usually don't do that either, i.e. I open a file, fgets() lines and use sscanf()
for disecting the line. Both \r and \n are treated as white space if they're left
in that line so they don't bother me.

I use that System thingie for writing formats alien to the current platform.

kind regards,

Jos

[AdrianH]

I usually don't do that either, i.e. I open a file, fgets() lines and use sscanf()
for disecting the line. Both \r and \n are treated as white space if they're left
in that line so they don't bother me.

I use that System thingie for writing formats alien to the current platform.

kind regards,

Jos

So you are saying even though fgets() fails to get the line correctly, your use of sscanf() will basicly ignore that fact?

That will work in a lot of cases, but I do not see it working in cases where you need to parse a line at a time for a file that was written on a different platform. Unix EOLs will actually work for all OSs (well at least between the three I mentioned) in the manner you are suggesting, but between Mac and Windoze, it is a fight to the death. ;)


Adrian

[JosAH]

So you are saying even though fgets() fails to get the line correctly, your use of sscanf() will basicly ignore that fact?

That will work in a lot of cases, but I do not see it working in cases where you need to parse a line at a time for a file that was written on a different platform. Unix EOLs will actually work for all OSs (well at least between the three I mentioned) in the manner you are suggesting, but between Mac and Windoze, it is a fight to the death. ;)


Adrian

I didn't know that. The MAC does \n\r doesn't it? I thought that a simple fgets()
goes as far as the \n on Windows machines. The \r would end up on the next
line just counting for a white space. Isn't that true? Or is fgets() stupid enough
to chop off the last char in its buffer unconditionally ?

kind regards,

Jos

[AdrianH]

I didn't know that. The MAC does \n\r doesn't it? I thought that a simple fgets()
goes as far as the \n on Windows machines. The \r would end up on the next
line just counting for a white space. Isn't that true? Or is fgets() stupid enough
to chop off the last char in its buffer unconditionally ?

kind regards,

Jos

I don't know for sure, but I do know that Windows does not recognise the Unix EOL. A perfect example of that is opening a Unix text file in notepad. It thinks it is all on one line.

Because of that, since the Mac reverses the way Window's does it, it would probably do the same thing. And if the Mac file had two consecutive EOLs, it would probably recognise it as one (the first char of the fist EOL and the last char of the last EOL would be ignored) in the Windows world.

This wasn't a big issue before. But now with all these different platforms are networked together, it can become an issue if the file is mistakenly transfered another via a binary protocol.


Adrian

[weaknessforcats]

All of this file handling is interesting but the original question was:

I want to know what is carriage return value in C.

and that is \r.

The counting of lines of code is a separate problem.

[AdrianH]

All of this file handling is interesting but the original question was:


and that is \r.

The counting of lines of code is a separate problem.

Actually, even though that was the original question, that was not the intent. Hararnkhor needed a way of counting lines of code, so he/she should be aware of the problems.


Adrian