Talk:C file input/output

From Wikipedia, the free encyclopedia

This article is supported by the Wikipedia:WikiProject C++. Please visit the project page for more details on the project.

Contents

[edit] Faulty example

Removed from the end of the article:

A convenient, but non-standard, way to find the length of a file in C is:

FILE *f = fopen("filename", "rb"); fseek(f, 0L, SEEK_END); length = tell(f); rewind(f);

There are several problems with this code; first of all, tell is not a standard C library function. Replacing it with ftell, the code will compile (assuming length is declared long int somewhere), but it still won't work everywhere; fseek is not guaranteed to produce meaningful results on binary files with SEEK_END. And then there's one minor nitpick: the programmer takes care to rewind the file to the beginning when he's "done" with it, but he never closes the file! That's not a bug, but it may well be a mistake.

[edit] Merge fopen and fclose

It's like yin and yang ... it's awkward to discuss one without the other, and certainly there is repetition in each fopen and fclose. However, a better question is what should the merged article be named? I suggest:

Please suggest! (Or argue if these two files should be not be merged). +mwtoews 00:05, 29 January 2007 (UTC)

Okay, merging them to C file input/output, using the content-base from fopen. +mwtoews 08:55, 1 February 2007 (UTC)

[edit] Merge everything else

I'd like to see all the file I/O functions merged into this article — fread, fwrite, fgetc, fflush, getchar, putchar. They're all permanent stubs, since there's nothing interesting to say about them, and Wikipedia is not a how-to guide to C programming, nor is Wikipedia a man page. (Nobody should be coming to Wikipedia to read a man page, because of the potential for vandalism. There are authoritative, non-modifiable HTML man pages available elsewhere on the Web.)

printf and gets definitely deserve their own articles. rewind, remove, and tmpfile are obscure enough (and substub enough) that I wouldn't want to bring them into an article on file I/O unnecessarily; I'm prodding them now.

Finally, I see no reason this article should be at C file input/output instead of the shorter and universally recognized term C file I/O. It looks like there's been some ambivalence about that term on Wikipedia in the past, judging from the inconsistency between Category:Input/Output and the article Input/output. --Quuxplusone 03:47, 31 March 2007 (UTC)

I support the merges, however I'm pondering the "file" part of the name, as many of these functions aren't exclusive to only files .. they can be data streams too! As far as the "I/O" vs "input/output" name, I don't have any strong opinion, although Google search hits for "file i/o" is 1.0 M vs 0.1 M for "file input/output". So in light that this may not be exclusive to files, perhaps a better and general name might be C data I/O or C data input/output, or would this be making things unnecessarily complex? +mwtoews 19:30, 31 March 2007 (UTC)

[edit] Bytes grown up?

On systems where int and char are the same size, even the "good" example will suffer from the indistinguishability of EOF and some character's value. The proper way to handle this situation is to check feof and ferror after getchar returns EOF. If feof indicates that end-of-file has not been reached, and ferror indicates that no errors have occurred, then the EOF returned by getchar can be assumed to represent an actual character. These extra checks are rarely done, because most programmers assume that their code will never need to run on one of these "big char" systems.

I believe some statements are wrong in above paragraph. Byte is always 8 bits long and char is always a single byte. See the ISO sheet! Do not mistake modern wide char (as in type) with char (as in byte). *getc* functions always return unsigned char casted to int as it is mentioned in one paragraph earlier. AFAIK int due to standard is always at least 16 bits long so it will never be the same size as char. Anyway its good to mention feof(), ferror() and clearerr(); —Preceding unsigned comment added by 194.29.147.6 (talk • contribs)
In C, a "char" is one "byte" wide, and a "byte" is the unit of storage required to hold one "char". If it requires 32 bits to hold a "char" on some big-char implementation, then that implementation's bytes must by definition have at least 32 bits. "The ISO sheet" is irrelevant here; the document you should be consulting is the ISO C standard. --Quuxplusone 05:30, 7 June 2007 (UTC)
I believe Quuxplusone is correct. sizeof(char) must always be 1, but it needn't correspond to 8 bits. I think I've heard of systems where a char is more than 8 bits, but I don't know of any specific examples (other than really old computers that didn't use 8-bit bytes). - furrykef (Talk at me) 18:45, 2 October 2007 (UTC)