Talk:C file input/output

This is the talk page for discussing improvements to the C file input/output article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Computing Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.

C/C++ High‑importance

	This article is within the scope of WikiProject C/C++, a collaborative effort to improve the coverage of C and C++ topics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.C/C++Wikipedia:WikiProject C/C++Template:WikiProject C/C++C/C++ articles
High	This article has been rated as High-importance on the importance scale.
	This article falls within the scope of C.

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.

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

EOF Pitfall Example

The EOF Pitfall "Mistaken" code and "Corrected" code are char-for-char identical. Am I missing something here? --DragoonWraith (talk) 05:03, 16 August 2010 (UTC)[reply]

In the first line, one's a char and the other is an int. Since the EOF marker is negative, the one with the "char" in it will never find it. However, this is pretty simple stuff and most tutorials and reference books also mention it. It seems kinda pointless to me-- especially since this is an encyclopedia and not a tutorial. So, I don't see why it's included at all. Anybody? ScottishPig (talk) 02:52, 21 April 2011 (UTC)[reply]

Windows Issue when printing 0xA

So as noted in the carriage return page here in Wikipedia, Windows interprets a 'new line character' '\n' as being a carriage-return '\r' followed by the newline. I am currently working on a project where I output binary files and for a second I thought I was going crazy when I noticed I had extra bits all over the place. It turns out that using fputc, or any other such function with an output character value of 0x0A on a Windows O.S. will cause the output of 0x0D right before it. I.E. if I do the following fputc('\n', fp); or fputc(10, fp); close the file, and examine it in a hex editor, there will be two characters written, '\r' and '\n'. Does anyone know a way around this? 76.26.238.56 (talk) 16:59, 21 November 2010 (UTC)[reply]

This issue is a behavior of the filesystem (VFAT, FAT32, etc.) your Windows OS is writing on. For some historical reasons, when writing to a text file on such filesystem, the driver converts '\n' into "\r\n" automatically. To avoid this behavior, you need to explicitly specify the use of binary mode when opening the file: see the flag "b" in fopen. Teuxe (talk) 13:13, 24 July 2012 (UTC)[reply]

Single page for C input/output functions

Based on Talk:C standard library#Pages for each function and WP:NOTMANUAL

The following pages essentially discuss the same topic of C input/output functions: stdio.h, putc, putchar, fgets, fgetws, fread, fseek, ferror, gets, setvbuf, feof, fgetpos, ungetc. I propose to cleanup these pages by removing the material that fails WP:NOTMANUAL and by merging the remains into C file input/output.1exec1 (talk) 23:17, 8 October 2011 (UTC)[reply]

Necessary information about functions in c are not included in C file input/output. They need to be explained with examples. So I create the page Putc. But it is good idea to merge it. SoniyaR (talk) 06:14, 12 October 2011 (UTC)[reply]

If functions you mentioned are merged in C file input/output, detailed info. and examples will be cleaned up. There will be only small sections of these functions in a big article. SoniyaR (talk) 13:23, 12 October 2011 (UTC)[reply]

These examples and detailed bits are somewhat out of scope of Wikipedia (see WP:NOTMANUAL). So yes, they will be removed during the merge. However, the content itself won't disappear, since there's an initiative to import the articles about C functions to Wikibooks at b:C_Programming/C99_Reference. I expect that the merge won't happen before the import process is finished. Thus, at the end we will have a concise list of functions in this article and detailed stuff with examples at Wikibooks. What do you think about that? 1exec1 (talk) 18:12, 12 October 2011 (UTC)[reply]

Move discussion in progress

There is a move discussion in progress which affects this page. Please participate at Talk:C standard library - Requested move and not in this talk page section. Thank you. —RM bot 09:40, 8 November 2011 (UTC)[reply]

printk

printk redirects to this page; but this (Linux-specific?) function is a private kernel call (i.e. intended to be called only from kernel mode); it should not be considered as a classic C file I/O. Teuxe (talk) 13:41, 24 July 2012 (UTC)[reply]

I think the printk redirect was the victim of a hasty effort to clean up and avoid duplication in a whole lot of programming man-page-like articles. It even used to be its own article, and I don’t think any content from that article got merged anywhere. See Talk:printf#Single page for format string and Talk:C standard library/Archive 2#Pages for each function and WP:NOTMANUAL. Vadmium (talk, contribs) 05:35, 17 August 2012 (UTC).[reply]

Add section for old UNIX-like "unbuffered" I/O functions?

Should a section be made that gives lip-service to the old UNIX-like "unbuffered" I/O functions? These are read(), write(), open(), creat(), close(), lseek(), and unlink(). Jason Quinn (talk) 04:25, 16 December 2012 (UTC)[reply]

They're still the system calls used to implement stdio and other I/O libraries, and there's a bit of relatively poor manual-y coverage already, so linking might be better. However, those functions really shouldn't each have their own page - making a nice consolidated page on what I/O functionality POSIX supports in addition to the C standards would be better. strcat (talk) 16:39, 17 December 2012 (UTC)[reply]

Including angle brackets in references to headers

Using '<stdio.h>' instead of 'stdio.h' in every reference to to a header file is just stupid, redundant and wrong. The file is called "stdio.h". The brackets are just part of the C syntax, not the name of the file, and are not even specific to standard system headers.

The uniform use of angle brackets should be completely removed from all of the C header file pages, except for the rare cases where they're actually correct/relevant (e.g. source code examples). — Preceding unsigned comment added by 82.9.176.129 (talk) 16:58, 1 September 2014 (UTC)[reply]

Coding Style

I would like to match the curly braces on a single style and before, after the if insert a blank line and omit the dispensable void in parameter list, so you can read the code better

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
    char buffer[5] = {0};  /* Initialized to zeroes */
    int i;
    FILE *fp = fopen("myfile", "rb");

    if (fp == NULL) {
        perror("Failed to open file \"myfile\"");
        return EXIT_FAILURE;
    }

    for (i = 0; i < 5; i++) {
        int rc = getc(fp);
        if (rc == EOF) {
            fputs("An error occurred while reading the file.\n", stderr);
            return EXIT_FAILURE;
        }
        buffer[i] = rc;
    }

    fclose(fp);

    printf("The bytes read were... %x %x %x %x %x\n", buffer[0], buffer[1], buffer[2], buffer[3], buffer[4]);

    return EXIT_SUCCESS;
}