139

What is the simplest way (least error-prone, least lines of code, however you want to interpret it) to open a file in C and read its contents into a string (char*, char[], whatever)?

Ciro Santilli OurBigBook.com
  • 347,512
  • 102
  • 1,199
  • 985
Chris Bunch
  • 87,773
  • 37
  • 126
  • 127
  • 12
    "simplest way" and "least error-prone" are often opposites of each other. – Andy Lester Oct 06 '08 at 14:37
  • 28
    "simplest way" and "least error prone" are actually synonymous in my book. For example, the answer in C# is `string s = File.ReadAllText(filename);`. How could that be simpler and more error prone? – Mark Lakata Apr 07 '14 at 19:54

13 Answers13

186

I tend to just load the entire buffer as a raw memory chunk into memory and do the parsing on my own. That way I have best control over what the standard lib does on multiple platforms.

This is a stub I use for this. you may also want to check the error-codes for fseek, ftell and fread. (omitted for clarity).

char * buffer = 0;
long length;
FILE * f = fopen (filename, "rb");

if (f)
{
  fseek (f, 0, SEEK_END);
  length = ftell (f);
  fseek (f, 0, SEEK_SET);
  buffer = malloc (length);
  if (buffer)
  {
    fread (buffer, 1, length, f);
  }
  fclose (f);
}

if (buffer)
{
  // start to process your data / extract strings here...
}
Nils Pipenbrinck
  • 83,631
  • 31
  • 151
  • 221
  • Awesome, that worked like a charm (and is pretty simple to follow along). Thanks! – Chris Bunch Oct 06 '08 at 14:43
  • 4
    I would also check the return value of fread, since it might not actually read the entire file due to errors and what not. – freespace Oct 06 '08 at 14:45
  • 2
    Along the lines of what freespace said, you might want to check to ensure the file isn't huge. Suppose, for instance, that someone decided to feed a 6GB file into that program... – rmeador Oct 06 '08 at 14:46
  • Definitely, just like Nils said originally, I'm going to go look up the error codes on fseek, ftell, and fread and act accordingly. – Chris Bunch Oct 06 '08 at 14:47
  • Seeking to the end just so you can call ftell? Why not just call stat? – dicroce Oct 06 '08 at 15:07
  • 9
    like rmeador said, fseek will fail on files >4GB. – KPexEA Oct 06 '08 at 15:33
  • 7
    True. For large files this solution sucks. – Nils Pipenbrinck Oct 06 '08 at 15:52
  • 2
    I haven't suggested using stat simply because it's not ANSI C. (At least I think so). Afaik the "recommended" way to get a file-size is to seek to the end and get the file offset. – Nils Pipenbrinck Oct 06 '08 at 15:53
  • This is good and easy... but it will choke if you need to read from a pipe rather than an ordinary file, which is something that most UNIX programs will want to do at some point. – Dan Lenski Oct 06 '08 at 16:27
  • 46
    Since this is a landing page, I would like to point out that `fread` does not zero-terminate your string. This can lead to some trouble. – ivan-k Sep 08 '14 at 18:36
  • 32
    As @Manbroski said, buffer need to be '\0' terminated. So I would change `buffer = malloc (length + 1);` and add after fclose : `buffer[length] = '\0';` (validated by Valgrind) – soywod Oct 28 '16 at 08:37
  • Make this answer into a nice function with error checking + call example for copy pasters :-) – Ciro Santilli OurBigBook.com Mar 11 '17 at 20:41
  • 4
    `fseek (f, 0, SEEK_END);` is explicitly undefined behavior for a binary stream. [7.21.9.2 The `fseek` function, paragraph 3](http://port70.net/~nsz/c/c11/n1570.html#7.21.9.2p3): *... A binary stream need not meaningfully support fseek calls with a `whence` value of `SEEK_END`.* And [per footnote 268 of the C standard](http://port70.net/~nsz/c/c11/n1570.html#note268): *Setting the file position indicator to end-of-file, as with `fseek(file, 0, SEEK_END)`, has undefined behavior for a binary stream...* – Andrew Henle Nov 09 '17 at 12:17
  • 4
    I don't think this was ever intended to be a large file solution. Reading GBs of files into a single string is not a good idea. But for smaller files it might be just fine :) – ericcurtin Sep 14 '18 at 11:19
  • How do you separate the lines in the buffer though? Checking for new lines? – Zap Aug 30 '19 at 21:06
42

Another, unfortunately highly OS-dependent, solution is memory mapping the file. The benefits generally include performance of the read, and reduced memory use as the applications view and operating systems file cache can actually share the physical memory.

POSIX code would look like this:

int fd = open("filename", O_RDONLY);
int len = lseek(fd, 0, SEEK_END);
void *data = mmap(0, len, PROT_READ, MAP_PRIVATE, fd, 0);

Windows on the other hand is little more tricky, and unfortunately I don't have a compiler in front of me to test, but the functionality is provided by CreateFileMapping() and MapViewOfFile().

Morgoth
  • 4,935
  • 8
  • 40
  • 66
Jeff Mc
  • 3,723
  • 1
  • 22
  • 27
  • 5
    Don't forget to check the return values from those system calls! – Toby Speight Feb 28 '18 at 10:50
  • 3
    must use off_t instead of int when calling lseek(). – ivan.ukr Jul 12 '18 at 05:06
  • 2
    Note that if the goal is to stably capture in memory the contents of a file at a given moment in time, this solution should be avoided, unless you are certain that the file being read into memory will not be modified by other processes during the interval over which the map will be used. See this [post](https://unix.stackexchange.com/q/519850/14960) for more information. – user001 May 20 '19 at 05:56
21

If "read its contents into a string" means that the file does not contain characters with code 0, you can also use getdelim() function, that either accepts a block of memory and reallocates it if necessary, or just allocates the entire buffer for you, and reads the file into it until it encounters a specified delimiter or end of file. Just pass '\0' as the delimiter to read the entire file.

This function is available in the GNU C Library, http://www.gnu.org/software/libc/manual/html_mono/libc.html#index-getdelim-994

The sample code might look as simple as

char* buffer = NULL;
size_t len;
ssize_t bytes_read = getdelim( &buffer, &len, '\0', fp);
if ( bytes_read != -1) {
  /* Success, now the entire file is in the buffer */
David Schumann
  • 13,380
  • 9
  • 75
  • 96
dmityugov
  • 4,390
  • 23
  • 18
  • 1
    I've used this before! It works very nicely, assuming the file you're reading is text (does not contain \0). – ephemient Oct 06 '08 at 16:34
  • NICE! Saves a lot of problems when slurping in whole text files. Now if there was a similar ultra simple way of reading a binary file stream until EOF without needing any delimiting character! – anthony Jan 05 '17 at 03:05
10

If you are reading special files like stdin or a pipe, you are not going to be able to use fstat to get the file size beforehand. Also, if you are reading a binary file fgets is going to lose the string size information because of embedded '\0' characters. Best way to read a file then is to use read and realloc:

#include <stdio.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>

int main () {
    char buf[4096];
    ssize_t n;
    char *str = NULL;
    size_t len = 0;
    while (n = read(STDIN_FILENO, buf, sizeof buf)) {
        if (n < 0) {
            if (errno == EAGAIN)
                continue;
            perror("read");
            break;
        }
        str = realloc(str, len + n + 1);
        memcpy(str + len, buf, n);
        len += n;
        str[len] = '\0';
    }
    printf("%.*s\n", len, str);
    return 0;
}
Jake
  • 2,106
  • 1
  • 24
  • 23
  • 4
    This is O(n^2), where n is the length of your file. All solutions with more upvotes than this are O(n). Please don't use this solution in practice, or use a modified version with multiplicative growth. – Clark Gaebel Feb 24 '16 at 19:26
  • 3
    realloc() can extend the existing memory to the new size without copying the old memory to a new larger piece of memory. only if there are intervening calls to malloc() will it need to move memory around and make this solution O(n^2). here, there's no calls to malloc() that happen in between the calls to realloc() so the solution should be fine. – Jake Mar 07 '16 at 18:42
  • 3
    You could read directly into the "str" buffer (with an appropriate offset), without needing to copy from a intermediate "buf". That technique however that will generally over allocate memory needed for the file contents. Also watch out for binary files, the printf will not handle them correctly, and you probably don't want to print binary anyway! – anthony Jan 05 '17 at 03:14
6

Note: This is a modification of the accepted answer above.

Here's a way to do it, complete with error checking.

I've added a size checker to quit when file was bigger than 1 GiB. I did this because the program puts the whole file into a string which may use too much ram and crash a computer. However, if you don't care about that you could just remove it from the code.

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

#define FILE_OK 0
#define FILE_NOT_EXIST 1
#define FILE_TOO_LARGE 2
#define FILE_READ_ERROR 3

char * c_read_file(const char * f_name, int * err, size_t * f_size) {
    char * buffer;
    size_t length;
    FILE * f = fopen(f_name, "rb");
    size_t read_length;
    
    if (f) {
        fseek(f, 0, SEEK_END);
        length = ftell(f);
        fseek(f, 0, SEEK_SET);
        
        // 1 GiB; best not to load a whole large file in one string
        if (length > 1073741824) {
            *err = FILE_TOO_LARGE;
            
            return NULL;
        }
        
        buffer = (char *)malloc(length + 1);
        
        if (length) {
            read_length = fread(buffer, 1, length, f);
            
            if (length != read_length) {
                 free(buffer);
                 *err = FILE_READ_ERROR;

                 return NULL;
            }
        }
        
        fclose(f);
        
        *err = FILE_OK;
        buffer[length] = '\0';
        *f_size = length;
    }
    else {
        *err = FILE_NOT_EXIST;
        
        return NULL;
    }
    
    return buffer;
}

And to check for errors:

int err;
size_t f_size;
char * f_data;

f_data = c_read_file("test.txt", &err, &f_size);

if (err) {
    // process error
}
else {
    // process data
    free(f_data);
}
ACascarino
  • 4,340
  • 1
  • 13
  • 16
Joe Cool
  • 175
  • 2
  • 11
  • 2
    Just one question: the `buffer` you allocated with `malloc(length +1)`, is not being freed. Is that something the consumer of this method shall do, or there is no need for `free()` the allocated memory? – Pablosproject Sep 17 '20 at 09:44
  • 1
    if an error has not occurred, free(f_data); should be called. thks for pointing that out – Joe Cool Sep 20 '20 at 00:23
  • 2
    You misspelled "too" in `FILE_TO_LARGE` – user11171 Sep 02 '21 at 14:31
5

What is the simplest way (least error-prone, least lines of code, however you want to interpret it) to open a file in C and read its contents into a string ...?

Sadly, even after years, answers are error prone and many lack proper string formation and error checking.

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

// Read the file into allocated memory.
// Return NULL on error.
char* readfile(FILE *f) {
  // f invalid? fseek() fail?
  if (f == NULL || fseek(f, 0, SEEK_END)) {
    return NULL;
  }

  long length = ftell(f);
  rewind(f);
  // Did ftell() fail?  Is the length too long?
  if (length == -1 || (unsigned long) length >= SIZE_MAX) {
    return NULL;
  }

  // Convert from long to size_t
  size_t ulength = (size_t) length;
  char *buffer = malloc(ulength + 1);
  // Allocation failed? Read incomplete?
  if (buffer == NULL || fread(buffer, 1, ulength, f) != ulength) {
    free(buffer);
    return NULL;
  }
  buffer[ulength] = '\0'; // Now buffer points to a string

  return buffer;
}

Note that if the text file contains null characters, the allocated data will contain all the file data, yet the string will appear to be short. Better code would also return the length information so the caller can handle that.

char* readfile(FILE *f, size_t *ulength_ptr) {
  ...
  if (ulength_ptr) *ulength_ptr == *ulength;
  ...
} 

As the string is allocated, be sure to free the returned pointer when done.

chux - Reinstate Monica
  • 143,097
  • 13
  • 135
  • 256
4

If the file is text, and you want to get the text line by line, the easiest way is to use fgets().

char buffer[100];
FILE *fp = fopen("filename", "r");                 // do not use "rb"
while (fgets(buffer, sizeof(buffer), fp)) {
... do something
}
fclose(fp);
selwyn
  • 1,184
  • 2
  • 10
  • 20
3

If you're using glib, then you can use g_file_get_contents;

gchar *contents;
GError *err = NULL;

g_file_get_contents ("foo.txt", &contents, NULL, &err);
g_assert ((contents == NULL && err != NULL) || (contents != NULL && err == NULL));
if (err != NULL)
  {
    // Report error to user, and free error
    g_assert (contents == NULL);
    fprintf (stderr, "Unable to read file: %s\n", err->message);
    g_error_free (err);
  }
else
  {
    // Use file contents
    g_assert (contents != NULL);
  }
}
SleepyCal
  • 5,739
  • 5
  • 33
  • 47
3

Just modified from the accepted answer above.

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

char *readFile(char *filename) {
    FILE *f = fopen(filename, "rt");
    assert(f);
    fseek(f, 0, SEEK_END);
    long length = ftell(f);
    fseek(f, 0, SEEK_SET);
    char *buffer = (char *) malloc(length + 1);
    buffer[length] = '\0';
    fread(buffer, 1, length, f);
    fclose(f);
    return buffer;
}

int main() {
    char *content = readFile("../hello.txt");
    printf("%s", content);
}
BaiJiFeiLong
  • 3,716
  • 1
  • 30
  • 28
1
// Assumes the file exists and will seg. fault otherwise.
const GLchar *load_shader_source(char *filename) {
  FILE *file = fopen(filename, "r");             // open 
  fseek(file, 0L, SEEK_END);                     // find the end
  size_t size = ftell(file);                     // get the size in bytes
  GLchar *shaderSource = calloc(1, size);        // allocate enough bytes
  rewind(file);                                  // go back to file beginning
  fread(shaderSource, size, sizeof(char), file); // read each char into ourblock
  fclose(file);                                  // close the stream
  return shaderSource;
}

This is a pretty crude solution because nothing is checked against null.

Entalpi
  • 2,005
  • 22
  • 33
0

I will add my own version, based on the answers here, just for reference. My code takes into consideration sizeof(char) and adds a few comments to it.

// Open the file in read mode.
FILE *file = fopen(file_name, "r");
// Check if there was an error.
if (file == NULL) {
    fprintf(stderr, "Error: Can't open file '%s'.", file_name);
    exit(EXIT_FAILURE);
}
// Get the file length
fseek(file, 0, SEEK_END);
long length = ftell(file);
fseek(file, 0, SEEK_SET);
// Create the string for the file contents.
char *buffer = malloc(sizeof(char) * (length + 1));
buffer[length] = '\0';
// Set the contents of the string.
fread(buffer, sizeof(char), length, file);
// Close the file.
fclose(file);
// Do something with the data.
// ...
// Free the allocated string space.
free(buffer);
Erik Campobadal
  • 867
  • 9
  • 14
-2

I just ran a bunch of tests comparing using seek, lseek, stat, and fstat also comparing using file streams and file descriptors to see what seems to be the fastest. For the test I create a 100M file.

TL;DR - using file descriptors, fstat and read was the fastest and using file streams and seek was the slowest.

For the test I ran this on a small Linux box I have running a headless ArchLinux server. I ran the test: checking the file size, malloc a buffer, read the entire file into the buffer, close the file, free the buffer.

I ran the test 3 times with 1000 cycles each time and using clock_gettime to calculate the elapsed time.

Just simply comparing JUST the time it takes to get the file size using stat or fstat were at least 30% faster than using seek or lseek.

Comparing just the speed of using file streams vs file descriptors, they were pretty nearly the same - descriptors were about 1-3% faster.

In comparing getting the file size, opening the file, malloc a buffer, read the entire 100M, close the file and free the buffer -- using file descriptors and fstat were 6-8% faster than using seek or lseek. Probably because the bulk of the time is spent in the file read vs the getting the file size, which dilutes the overall performance benefit.

BTW - do not use fgetc and read the file 1 character at a time. This is crazy inefficient and really really slow! Like 1700% slower!!!!

Post BTW... here is chat gpt's answer - not bad... but as I showed above it should really use stat or fstat

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

char* read_file(const char* filename) {
    FILE* file = fopen(filename, "rb");
    if (file == NULL) {
        fprintf(stderr, "Failed to open file '%s'\n", filename);
        return NULL;
    }

    fseek(file, 0L, SEEK_END);
    long file_size = ftell(file);
    rewind(file);

    char* buffer = (char*) malloc(sizeof(char) * (file_size + 1));
    if (buffer == NULL) {
        fclose(file);
        fprintf(stderr, "Failed to allocate memory for file '%s'\n", filename);
        return NULL;
    }

    size_t bytes_read = fread(buffer, sizeof(char), file_size, file);
    if (bytes_read != file_size) {
        fclose(file);
        free(buffer);
        fprintf(stderr, "Failed to read file '%s'\n", filename);
        return NULL;
    }

    buffer[file_size] = '\0';

    fclose(file);
    return buffer;
}
-3

easy and neat(assuming contents in the file are less than 10000):

void read_whole_file(char fileName[1000], char buffer[10000])
{
    FILE * file = fopen(fileName, "r");
    if(file == NULL)
    {
        puts("File not found");
        exit(1);
    }
    char  c;
    int idx=0;
    while (fscanf(file , "%c" ,&c) == 1)
    {
        buffer[idx] = c;
        idx++;
    }
    buffer[idx] = 0;
}
  • 3
    Please don't allocate all the memory you *think* you'll need upfront. This is a perfect example of bad design. You should allocate memory as-you-go whenever it is possible to do so. It would be good design if you expect the file to be 10,000 bytes long, your program can't handle a file that's any other size, and you're checking the size and erroring out anyway, but that's not what is going on here. You really should learn how to code C correctly. – Jack G Jul 24 '20 at 00:21