Thread: fopening and fseeking: text or binary file?

It depends on what function you use to write each data item or struct. If you use fprintf(), then text mode should be fine. If you use fwrite(), then you need to use binary mode.

Just be careful what you do with text files. On windows, newline characters are two bytes ("\r\n"), but file open in text mode on Windows will only see a "\n". This can make reading Unix file on Windows / Windows files on Unix a bit interesting. (You should convert them. Things like FTP do this mostly automatically.)

EDIT: (Had an example of something here with fseek(), so if you saw it...) Oops, my example, and apperantly my knowledge, was flawed. Seems to work as expected. Might have to look into this.

UTF-8 should probably be read in text mode. I don't think UTF-8 enforces whether a newline is "\n" or "\r\n".

Generally, I don't find myself fseeking in text that much.

Originally Posted by stabu

Well, for operating on only parts of a file (which match a certain pattern) how far can you go with c? That's kind of Perl territory there (yeh, ok, python and ruby too).

All of which are written in C, so I would say that anything you can do in Perl, Python, Ruby, PHP, etc, can be done in C too - you just have to write a bit more code to do it.

I thought the fundamental problem is that if you're dealing with a lagre number of sometime dubious datafiles which might have a foreign language header, you could get certain characters being represented by two or more bytes, though they may appear to be a single character in the text.

I was surmising that binary mode ensures that every character is represented by one byte.

Any comments about how in the dark / in the light I am, welcome.

Multi-character characters [for want of a better word for it] still take up multiple "character positions", however, so it will have exactly the same effect in binary and in text-mode - they are one character only when representing them on the screen.

The only place where text or binary makes a difference is in the sense of newlines and file endings, and not all OS's have specific file-endings for text files [the latter goes back to CP/M and other ancient OS's, where the filesize was stored in blocks rather than bytes (to save space), and the only way to know where some random length text file ends was to put a marker in that position, typically CTRL-Z - all modern OS's that I know of store the number of bytes actually used in the file, so there's no meaning to have a special character at the end of the file].

--
Mats

Yes, but you will have to use non-C APIs, like POSIX, the Windows API, glib, etc. In any case, if you're dealing with UTF-8, you've probably already decided which platforms you are going to code for.