strncpy implementation too complicated in glibc

Question

I'm trying to understand string.h functions. Here is my own implementation of strncpy()

char * my_strncpy(char *dst, const char* src, int n)
{
    char *orig = dst;
    const char *hold = src;
    int count = 0, remain = 0;
    while(*(hold++))
            count++;
    if ( n > count )
    {
            remain = n - count;
            n = count;
    }
    while(n--)
            *dst++ = *src++;
    while(remain--)
            *dst++ = '\0';
    return orig;
}

But while looking at glibc implementation here, I'm wondering why it is too big and complicated.

I tested for execution time using "time" command. Both functions run almost same.
Can someone share knowledge on glibc strncpy() and what I'm missing in my_strncpy().

Answer 1

From a modern C programming perspective, that "Glibc" code is very badly written. It looks like a collection of premature optimizations for one particular platform with 32 bit alignment. If the compiler is crap, then you'll have to group bytes in units of the preferred alignment and copy them one such unit at a time. That's the main reason why the code looks so weird.

I would guess that the code was likely written a long time ago, when compilers were a lot worse at optimizing code and CPUs had less hardware support for things like these. The inconsistent, seemingly random way that they switch back and forth between prefix to postfix increment also suggests that the code was written for a poor compiler.

Apart from pre-mature optimization, the code is complete spaghetti, which there is no sensible explanation for. The complete lack of comments also suggests that the code was written by a bad programmer.

So to sum it up, there may or may not be various historical reasons why they wrote the code in this way, but there are lots of bad programming practice in the code which can't be dismissed as pre-mature optimizations.

Just dismiss that code as rubbish.

---

Also please note that the strncpy function is mainly obsolete and should be avoided. strncpy was only meant to be used for an ancient string format in Unix. It was never intended to be a safe version of strcpy. On the contrary, the function is dangerous and known to cause a lots of bugs because of accidental missing null terminations.

The standard specification of strncpy also forces it to do a lot of pointless things, like checking for null termination when you already know the length in advance. Also, one may wonder what good it does anyone to fill the remaining characters after the first \0 with even more \0. All of these pointless requirements make the function needlessly slow.

So there is never a reason to use strncpy anywhere in modern C code. The proper way to copy strings of a known length is this:

memcpy(str1, str2, str2len + 1);