Efficiency is just one of the issues with your library. Here are some other concerns.

Implementation as a header file. Most libraries are linked in to the code that uses it; yours is compiled in, by being #included as a header file. What happens if file1.c and file2.c each uses octo.h? Then when you try to link file1.o and file2.o together, each of your functions would be defined twice, which is a linking error.

Incomplete Python emulation. String libraries can actually be quite complicated. For example, which characters are considered whitespace? Traditionally, the whitespace characters are Tab, Newline, Vertical tab, Form feed, Carriage return, and Space, but Unicode defines many more whitespace characters, so the answer may vary by locale. Should len() count bytes, or should it count Unicode characters, assuming that its argument is a string encoded in UTF-8? If your library is inspired by Python, people may have an expectation that it behaves like Python.

Memory handling. Your rstrip() function clobbers the input string. C programmers sometimes tolerate such behaviour, if it's documented. However, the fact that your rstrip() returns a char * rather than void suggests that it returns the stripped string as a copy, rather than modifying the original. On the other hand, your slice() function returns a copy and leaves the original unmolested. In short, your library has no consistent memory-management policy, which is essential for any cohesive C library. As a result, anyone who uses it is likely to get segfaults and/or memory leaks.

Stray pointer dereference in len(). Your len() function has a statement *string++; that should be just string++;. By the way, if you had written (*string++); instead, you would have implemented a Caesar cipher shifting by 1.

You could use C library functions. Your len() is just strlen() (but returning a signed rather than unsigned int). Your lstrip() could use strspn() or isspace(). In short, get familiar with the C library's built-in functions before you write your own.

Efficiency is just one of the issues with your library. Here are some other concerns.

Implementation as a header file. Most libraries are linked in to the code that uses it; yours is compiled in, by being #included as a header file. What happens if file1.c and file2.c each uses octo.h? Then when you try to link file1.o and file2.o together, each of your functions would be defined twice, which is a linking error.

Incomplete Python emulation. String libraries can actually be quite complicated. For example, which characters are considered whitespace? Traditionally, the whitespace characters are Tab, Newline, Vertical tab, Form feed, Carriage return, and Space, but Unicode defines many more whitespace characters, so the answer may vary by locale. Should len() count bytes, or should it count Unicode characters, assuming that its argument is a string encoded in UTF-8? If your library is inspired by Python, people may have an expectation that it behaves like Python.

Memory handling. Your rstrip() function clobbers the input string. C programmers sometimes tolerate such behaviour, if it's documented. However, the fact that your rstrip() returns a char * rather than void suggests that it returns the stripped string as a copy, rather than modifying the original. On the other hand, your slice() function returns a copy and leaves the original unmolested. In short, your library has no consistent memory-management policy, which is essential for any cohesive C library. As a result, anyone who uses it is likely to get segfaults and/or memory leaks.

Stray pointer dereference in len(). Your len() function has a statement *string++; that should be just string++;. By the way, if you had written (*string)++; instead, you would have implemented a Caesar cipher shifting by 1.

You could use C library functions. Your len() is just strlen() (but returning a signed rather than unsigned int). Your lstrip() could use strspn() or isspace(). In short, get familiar with the C library's built-in functions before you write your own.