Checking for end of lines in low level C

Steel Angel

I'm doing a coding project where I'm reading in data from a file into a linux kernel module (bad idea normally, I know, but we're ignoring that bit for the project).

Since this is kernel programming, stuff like fscan from stdio.h is off limits and I'm pretty sure I have to just iterate one character at a time into a buffer and then interpret the stuff in the buffer into variables. However, i can't remember what char equates to a carriage return and google is mainly turning up the various characters you get holding down alt when i search for ANSI characters.

Anyone know what i should be checking against?

Smasher

According to this a line feed is represented by 10.

ecco the dolphin

Depends on the text fie - traditional *nix text files end in \n only.

DOS/Windows text files tend to end in \r\n.

Old Mac files apparently end in \r, although I am uncertain how it behaves now that the new Mac OSs are on a *nix base. I'd guess \n, but am not sure.

Janin

Steel Angel wrote: »

I'm doing a coding project where I'm reading in data from a file into a linux kernel module (bad idea normally, I know, but we're ignoring that bit for the project).

Since this is kernel programming, stuff like fscan from stdio.h is off limits and I'm pretty sure I have to just iterate one character at a time into a buffer and then interpret the stuff in the buffer into variables. However, i can't remember what char equates to a carriage return and google is mainly turning up the various characters you get holding down alt when i search for ANSI characters.

Anyone know what i should be checking against?

Here's a table of the ASCII set

Assuming the file is in UNIX format, you can check for a character equal to '\n'. Is there a maximum size of a line, or can they be of any length? If the latter, is the data from a streaming source or a buffer?

If it's from a buffer, just mark the start, iterate until you reach '\n', mark that, then memcpy (or whatever you have in the kernel) into an appropriately sized buffer.

If you're reading from a stream, allocate chunks of some fixed size and read into them byte-by-byte. When you reach '\n', join all the buffers together.

Steel Angel

Janin wrote: »

Assuming the file is in UNIX format, you can check for a character equal to '\n'. Is there a maximum size of a line, or can they be of any length? If the latter, is the data from a streaming source or a buffer?

If it's from a buffer, just mark the start, iterate until you reach '\n', mark that, then memcpy (or whatever you have in the kernel) into an appropriately sized buffer.

If you're reading from a stream, allocate chunks of some fixed size and read into them byte-by-byte. When you reach '\n', join all the buffers together.

There's no size limit to the lines, but the file itself is static and we don't have to worry about someone altering it on the fly for the assignment. Not sure which this falls under (though I think the former), I've been doing higher level stuff for years where I had APIs to work with.

Janin

Well, if there would (for example) never be a line longer than 1024 bytes, you could just read them into a buffer of that size, and then replace the first '\n' you found with a NULL.

DrFrylock

eecc wrote: »

Depends on the text fie - traditional *nix text files end in \n only.

DOS/Windows text files tend to end in \r\n.

Old Mac files apparently end in \r, although I am uncertain how it behaves now that the new Mac OSs are on a *nix base. I'd guess \n, but am not sure.

This is correct. I believe that MacOS X uses \n as the newline.