Maybe thats how the idea came up. But it ended up being more of a way to lock people into WINBLOWS specific code and make porting away from windows harder.

Also nobody seemed to get the parameters right, it ischar* dest, const char* src

... and for compiler that wants to optimize as much as possible

Actually, I would bet the amount of strn.* functions in the Linux kernel overwhelms the str[^n]+ ones. At least, that is what I would expect.

Well, of course. Here, lets make it complete:

char* strcpy(char* dest, const char* src) {
   char* temp = dest;
   while( *dest++ = *src++ );
   return temp;
}

Or, better yet:

#include <algorithm>

char* strncpy(char* dest, const char* src, const size_t len) {
   std::copy(src, src+len, dest); // hooray for the STL!
   *(dest+len-1) = 0;
   return dest;
}

If in doubt, benchmark

-rwxrwxrwx+ 1 Administrators None   248 Mar  9 22:46 c_version.c*
-rwxr-xr-x  1 ppridham       None  7691 Mar  9 22:47 c_version.exe*
-rwxrwxrwx+ 1 Administrators None   335 Mar  9 22:47 stl_version.cpp*
-rwxr-xr-x  1 ppridham       None 41201 Mar  9 22:47 stl_version.exe*

Huh. Pretty bloated in Cygwin it seems.

Better with -Os and maybe with -fomit-frame-pointer
Also a mingw und UPx compressing might be interesting.

Carrus85 version of strncpy (no optimizations, -Os):

-rwxr-xr-x 1 hoho users 6644 Mar 10 10:48 a.out
-rwxr-xr-x 1 hoho users 6604 Mar 10 10:48 a.out

libc strncpy:

-rwxr-xr-x 1 hoho users 6525 Mar 10 10:50 a.out
-rwxr-xr-x 1 hoho users 6517 Mar 10 10:50 a.out

I wondeor how it is possible that libc's strncpy creates smaller executable than the function Carrus gave

Seems to me as there isn't much difference between C and C++, not at least under Linux

When did A.cc become the Royal Benchmarking Society? Some of the threads have become kind of like Programmer Mythbusters . "Is Java REALLY slower? Does STL really bloat your exes? Find out with your friendly host, HoHo, and his benchmarking machine!".

The community has grown wiser

How very wise. Another little known fact is that for statements also make your programs larger!

The posted strncpy() replacement also violates the semantics of strncpy, namely that the destination buffer is padded up to the length if the source is shorter. And it's invalid if called with length 0.

There's no reason to reinvent these functions except for better portability... because doing so creates problems like this that lurk, just waiting to be exploited in released code.