I have looked at the source code of some standard C functions and wondered what the reason is for null-terminating a string other than to find out its length.


The strlcat() function which is defined in the string.h header.

size_t strlcat(dst, src, siz)
    char *dst;
    const char *src;
    size_t siz;
    register char *d = dst;
    register const char *s = src;
    register size_t n = siz;
    size_t dlen;

    /* Find the end of dst and adjust bytes left but don't go past end */
    while (n-- != 0 && *d != '\0')
    dlen = d - dst;
    n = siz - dlen;

    if (n == 0)
        return(dlen + strlen(s));
    while (*s != '\0') {
        if (n != 1) {
            *d++ = *s;
    *d = '\0';

    return(dlen + (s - src));   /* count does not include NUL */

Why is the line *d = '\0'; necessary?

The string gets null terminated even if the function doesn't return the string but a value of the type size_t

  • strlcat is not part of the "classic" libc API; how are you suggesting to implement strcat without NULL termination? Jan 3 at 23:32
  • 2
    You don't think that being able to determine the length from the string pointer alone is sufficient motivation?
    – Erik Eidt
    Jan 3 at 23:54
  • One would just say "so store in the length in the object, beside the character contents". I think this boils down to "why is null termination used instead of caching the string length"
    – Alexander
    Jan 4 at 2:41
  • 3
    "The string gets null terminated even if the function doesn't return the string" - the function does return the string, it's just that it does so via an output parameter dst ("the destination string"), which it modifies (suppose dst was "dddd\0", and src was "ssss\0"; the code changes dst to "ddddssss\0"). Jan 4 at 6:14

A C-string is by definition a sequence of characters ending in a zero byte. If the zero byte is not there, then any code treating the characters as a C string will likely invoke undefined behaviour, and likely crash or worse.

If you can’t determine the length of a C string, then you cannot know whether any character is part of the C-string or not. Your question is like “other than the fact that it will explode, are there any other reasons not to put dynamite in the oven and turn the oven on?”

  • 2
    Crashing immediately in the function that received the not-a-string is positively the best-case scenario. Another likely scenario is that your program continues on, then billions of nanoseconds later something "impossible" happens
    – Caleth
    Jan 5 at 10:10
  • Some people still think that a crash is the worst possible bug (especially once the application is in the hand of end users). From my experience watching people on a fast modern computer including phones, they don’t even consciously notice a crash - they just tap on the application icon again and continue. But data corruption can have very unpleasant consequences.
    – gnasher729
    Jan 5 at 20:03

To answer the question strictly, there is no other reason to terminate a string, other than as a means for determining its length.

The null terminator is not necessary if you store a fixed-length string, whose exact length is fixed at compile time.

However, if you want a variable-length string, there has to be some way of identifying its length when processing it. Pascal used an integer prefix. C uses a null terminator.

As a side note, a string is fundamentally an array of characters (and traditionally, characters are fundamentally an integer of one byte length), and the same general principles apply to any array.

A fixed length array with elements of fixed size does not need a method of determining its length, because it is a compile-time constant. A variable length array needs a method of determining its length. The alternatives are either a length prefix, or a sentinel element that marks the end of the array. The null terminator is the sentinel element that marks the end of a string.

Not the answer you're looking for? Browse other questions tagged or ask your own question.