What is the advantage of strlmove vs strmove in C?

Question

Hi,

To trim the leading spaces we are using strmove. But we were advised to use strlmove instead of strmove. I have read and used strlcpy and strlcat. Whether strlmove does the similar functionality and what all are its advantages?

Edit 1: Thank you Mike B and Chris Young. This is how we use strlcpy.

size_t strlcpy(char *dst, const char *src, size_t size)
{
    strncpy(dst, src, size - 1);
    dst[size - 1] = '\0';
    return(strlen(src));
}

So I was just thinking of using strlmove() also in the same way. I want to confirm whether any specifications is defined regarding the implementation of strlmove(). I know this is one of the best place i can ask.

Edit 2: strlmove() is implemented the same way as strlcpy() and strlcat() using memmove().

size_t strlmove(char *dst, const char *src, size_t size)
{
    //Error if the size is 0
    //If src length is greater than size; 
    //   memmove(dst, src, size-1) and dst[size] = \0;
    //Otherwise
    //   memmove(dst, src, length(src));
    return source len;
}

Appreciate the help and support provided.

Thanks, Mathew Liju

Answer 1

strmove, strlmove, strlcpy, strlcat are all not standard C functions, so I can't comment on what they do without knowing which specific non-standard library you're using. Standard C provides strcpy, strcat, strncat, strncpy, memmove, memcpy, etc.

It makes sense to use strncpy over strcpy for safety if you don't know the source string will fit inside the destination buffer. However, strncpy has a major performance issue in that it always writes the amount of bytes specified for the size. That is:

char buf[4096];
strncpy(buf, "Hello", sizeof buf);

will write 'H', 'e', 'l', 'l', 'o' and fill the remaining 4091 bytes of buf with '\0'. Another thing to be aware of with strncpy is that it will not null-terminate the string if the size parameter is smaller than the source string length plus its null. For example:

char buf[5];
strncpy(buf, "Hello", sizeof buf);

will write 'H', 'e', 'l', 'l', 'o' into buf and it will not be null-terminated.

Answer 2

As Chris Young mentions, these routines are not standard (or as far as I known in wide, common use) so I can't be 100% certain with more specifics, but:

Typically the strl() variations of str() routines take an additional parameter that indicates the size of the destination buffer. The routine guarantees that it will not write data past the end of the buffer (since it knows the size). Usually strl() functions will also guarantee that they will place a terminating null character at the end of the string or at the end of the buffer (potentially truncating any string created there) so that you are also guaranteed to have a terminated string that will be generally OK to pass to other str() functions. Note that if the length of the buffer is specified as 0 (zero) the function will not place a terminating null character (as there's no room in the buffer for anything).

In my opinion, it's nearly always better to use a strl() (or strn()) function in preference to the corresponding str() routine to prevent buffer overruns.

Answer 3

Quick Google search reveals that the only mentions of strlmove function is in stackoverflow :). So it's probably not very common function.
But if we assume that this function is close by nature to strlcpy, this function is differ from strmove by using size parameter to move limited amount of bytes and make the destination string NULL terminated.

Answer 4

As Chris said, the functions you are using currently are non-std. ... even worse is that they are still highly inefficient and are still prone to errors. You chould be able to easily create a couple of APIs that use memcpy/memmove and take (char *)s which will work everywhere and likely be faster than the non-std. varients you are currently using.

However if you want someone else to do the heavy lifting, and get safety/usability for free, you could look at something like ustr ... which is meant to be easy to integrate, is std. C, safe, fast, and can deal with constant/automatic/utf8/dynamic strings. There are also other options.