User-made fgets() vs standard library fgets()

Question

The standard library function fgets() has two downsides:

• The second parameter of the function is of type int
• It leaves a trailing new-line character in the supplied buffer

I have made a simple function similar to fgets() excluding the above-mentioned downsides, to try to improve the efficiency of one of my programs that fetches the lines of a text file and terminates the char array at the new-line character using the function strcspn().

But is it really more efficient? Is there any reason why the standard library function has advantage over the following naive implemention?

#include <stdio.h>


char *my_fgets(char *buf, size_t maxCount, FILE *stream);


int main(int argc, char **argv)
{
    if (argc < 2)
    {
        fprintf(stderr, "Usage: %s [filename]", argv[0]);
    }

    FILE *fp;
    fp = fopen(argv[1], "r");

    if (!fp)
    {
        perror(argv[1]);
        return 1;
    }

    char buf[256];
    /*while (fgets(buf, sizeof(buf), fp))
    {
        buf[strcspn(buf, "\n")] = '\0';
        // . . .
        puts(buf);
    }*/

    while (my_fgets(buf, sizeof(buf) - 1, fp))
    {
        puts(buf);
    }

    return 0;
}


char *my_fgets(char *buf,
    size_t maxCount, FILE *stream)
{
    int ch;
    size_t n = 0;

    while ((ch = fgetc(stream)) != EOF)
    {
        if (ch == '\n' || n == maxCount)
        {
            break;
        }
        else
        {
            buf[n++] = ch;
        }
    }
    if (n == 0 && ch == EOF)
    {
        return NULL;
    }
    buf[n] = '\0';
    return buf;
}

Answer 1

Performance

Your use of fgetc() to fetch characters one by one guarantees that my_fgets() cannot compete with a sensibly optimized solution. To get good performance, you need to read some characters into a buffer via the read() syscall, and then consume the data directly from that buffer. Performing a full function call for every single byte is a lot of overhead.

Safety

fgets() is not safe for general usage: It will split long lines. This condition is generally unanticipated (your example code does not deal with this either, for instance), and will generally lead to wrong behavior when very long input lines are supplied to your program. The presence of the trailing \n could actually help you dealing with that problem. If you want safe software, you must explicitly handle the insufficient buffer case when using fgets(). Fail to do so, and you definitely have a bug waiting to strike. Your implementation does not even attempt to address this problem.

That is why I would strongly suggest using input functions that can deal with input lines of any lengths. On POSIX-compliant systems that would be getline(): This function allocates a sufficiently large buffer for you, so your only limit is available RAM. If getline() is not available on your platform, I would recommend to reimplement its functionality instead of a "somewhat better" version of fgets().

Answer 2

is it really more efficient?

No - not more efficient in performance. my_fgets(), at best, could have similar efficiency, yet even that is unlikely as fgets() has access to crafted assembly code and my_fgets() does not @Peter.

Yes, it may have a coding efficiency if the function goal is to get a line of user input and not save the '\n' as this is less to code than fgets() ... code_to_rid_\n()

---

Yet efficiency is secondary to functionality.

my_fgets() has minor trouble with input errors.

my_fgets() can drop characters, unlike fgets() @melpomene

The role of size_t maxCount differs by 1 from the similar argument of fgets().

---

Good try as the standard library fgets() has various weaknesses obliging coders to try for a better low level input line function.