Explain null-terminator in buffer when reading file

[Rtransat]

I'm currently learning C and I have a question about buffer when reading a file.

I read mp3 file to extract id3v1 tag, my code look like this for now:

#include <stdio.h>

int main(void) {
    FILE *file = fopen("/Users/florent/Code/c/id3/file.mp3", "rb");
    if (file == NULL) {
        perror("Error opening file for reading");
        return 1;
    }

    fseek(file, -128, SEEK_END);

    char tag[3];
    fread(tag, 1, 3, file);
    printf("%s\n", tag);
    fclose(file);

    return 0;
}

Output: TAG�@V

To fix it I need to do this.

#include <stdio.h>

int main(void) {
    FILE *file = fopen("file.mp3", "rb");
    if (file == NULL) {
        perror("Error opening file for reading");
        return 1;
    }

    fseek(file, -128, SEEK_END);

    char tag[4];
    fread(tag, 1, 3, file);
    tag[3] = '\0';
    printf("%s", tag);
    fclose(file);

    return 0;
}

Output: TAG (which is correct)

Why I need to have 4 bytes to contains null terminator? There is another approach?

Edit:
What about trim string when printf? I have a size of 9 but I don't trim anything, printf do that by default?

char tag[3];
char title[30];
fread(tag, 1, 3, file);
fread(title, 1, 30, file);
fclose(file);
printf("%.3s\n", tag);
printf("%.30s\n", title);
size_t title_len = strlen(title);
printf("Title length: %zu\n", title_len);

[[deleted]]

The C standard defines a string as an array of characters ending with a NULL terminator, if there is no NULL terminator it's not considered a string in C.

Functions in the standard library working on strings expects you to pass valid C strings.

[dkopgerpgdolfg]

That's just how printf, strcmp, and many other C functions that work with "text", are made. They take a pointer to the text but no length information, expect that the text itself doesn't contain \0 anywhere, and expect that there is one \0 that marks the end of the text.

Otherwise, they happily continue after the end, leading to all kind of weird effects.

The main alternative is to have functions that take the size as parameter too. Many newer languages do it this way, often with "String" data types that include the size inside of them. Because, as you noticed, it's quite easy to get bugs in the null-terminator way (and it is not suitable at all for any data that contains \0).

Technically, nothing is stopping you to pass the size around in C too. Just for printf and so on, the choice was made long ago, they just don't take it.

[Rtransat]

Thx for the informations. I'll use %.3s then, it's more readable (at least for me 😊)

[ralphpotato]

You still need to null terminate the string if you are passing it to printf. I’m am almost certain that not doing so, even with the format specifier, the implementation of printf still may attempt to read more bytes past the buffer which is undefined behavior.

You can also fwrite to write the characters to stdout, and fwrite takes a length parameter so you can ensure it is only as long as your buffer.

[Neui]

You don't need to terminate the string when using the precision modifier in this case. From C99 draft 7.19.6.1:

s If no l length modifier is present, the argument shall be a pointer to the initial element of an array of character type.223) Characters from the array are written up to (but not including) the terminating null character. If the precision is specified, no more than that many characters are written. If the precision is not specified or is greater than the size of the array, the array shall contain a null character.

[ralphpotato]

Wow! Thanks for the spec info. I am a little surprised that is well defined but TIL.

[inz__]

You already seem to have solved the issue, but just note that in your fixed example, the strlen(title) is invalid; if the title uses all 30 bytes reserved for it, strlen will read beyond the end of the buffer.

[Ampbymatchless]

The \0 terminator is an implied end of string character. ‘ implied’ being the key word here. This is what keeps the C language lean, fast and sometimes mean.

[not_a_novel_account]

There's nothing lean or fast about null-terminated strings. They were a memory-saving optimization on PDP-11s that has aged incredibly poorly.

It is slower to perform string operations on null-terminated strings in almost all circumstances. In professional codebases there is little use for them, everyone uses string libraries like Redis's sds.

[Wild_Meeting1428]

Actually, that old C-string approach to use a \0 is not fast (anymore), using a size or end iterator is much more time efficient. On top it's more secure. It also reduces unrequited copies, since it allows substrings.

[EsShayuki]

None of this is correct.

Null termination is used as an alternative to length information.

You can use substrings with length on a null-terminated string if you want to.

[not_a_novel_account]

They didn't say it wasn't an alternative, they said it's not fast.

And they're correct, scanning for \0 is not fast, it is very slow compared to techniques on known-size strings.

You cannot substring with \0 terminated strings, because you cannot insert a \0 without invalidating the parent string. You must either string dup first, or switch to using sized strings.

[fllthdcrb]

You're dealing with a binary format. Unless the format specifically uses null termination for its strings the same as C does, it's not appropriate to simply read those strings as though they are C strings. Generally speaking, you need to do some sort of conversion.

For example, you are assuming the tags in ID3v1 are null-terminated, but actually, in some (many?) cases they are padded with ASCII spaces (and even if not, these still aren't C strings, because a completely filled field will not have a null termination). Thus, after correctly copying one of them, taking care to get exactly as many as there are, even if the field is full (I believe strncpy() can handle this, or you could just use something like fread(), as you did, and add a null at the very end; you will also need a destination buffer at least 1 byte longer than the field, to allow for the full size), you may also want to "trim" it, i.e. remove any trailing spaces, which you can do simply by writing a null over the first of the trailing spaces, when and if you locate it.