Null character in fread() and strncpy() in c - c

Question

I am new programmer in general and I have start working now with c. I am trying to decode the IDEv3 mp3 tag and I came across with a variety of problems. While I was using the fread() and strncpy() commands I have noticed that both need to have the \n character as the end reference point. (Maybe I am wrong this is only an observation)
When I am printing the output they produce a non readable character. As a solution to overcome the problem I am using fread() for 4 Bytes instead of 3 in order to produce (8)\n characters (whole Byte), and a second step I am using strncpy() with 3 Bytes to an allocated memory which then I am using for printing. In theory when I am using fread() I should not encounter this problem.
A sample of code:
#include <stdio.h>
#include <stdlib.h>
typedef struct{
unsigned char header_id[3]; /* Unsigned character 3 Bytes (24 bits) */
}mp3_Header;
int main (int argc, char *argv[]) {
mp3_Header first;
unsigned char memory[4];
FILE *file = fopen( name.mp3 , "rb" );
if ( (size_t) fread( (void *) memory , (size_t) 4 , (size_t) 1 , (FILE *) file) !=1 ) {
printf("Could not read the file\n");
exit (0);
} /* End of if condition */
strncpy( (char *) first.header_id , (char *) memory , (size_t) 3);
printf ("This is the header_ID: %s\n", first.header_id);
fclose(file);
} /* End of main */
return 0;

Answer 1

Your observation with '\n' terminating strings isn't correct. Strings, in C, need to be terminated by a 0 byte (\0). However, some functions like fgets(), which are supposed to read lines from a file, take the \n at the end of the line as a terminator.
The problem with your code is that fread() ready binary data, and doesn't try to interpret that data as a string, which means it won't put the \0 at the end. But string functions, like strcpy, need this 0 byte to recognize the end of the string. strncpy stops after copying the \0 as well, but it won't ever put more bytes into the receiving string to prevent a buffer overflow. So it will copy your 3 bytes, but it won't put a \0 to the end of the string, as it would do if the string was shorter than the length argument.
So what you should do is declare header_id with one MORE element that what you actually need, and after the strcpy, set this extra element to \0. Like this:
strncpy( first.header_id , memory , 3);
first.header_id[3] = '\0';
Remember the 3 header bytes will go to array elements 0..2, so element 3 needs the terminator. Of course, you need to declare header_id[4] to have space for the extra \0.
Also note i omitted the type casts - you don't need them if your types are correct anyway. Passing an array to a function will pass a pointer to the 1st element anyway, so there's no need to cast the array header_id to a pointer in strncpy( (char *) first.header_id , (char *) memory , (size_t) 3);.

Answer 2

There are 2 correct ways of handling the header. I'm assuming the MP3 file has a IDV3 tag, so the file starts with "TAG" or "TAG+". So the part you want to read has 4 bytes.
a) You think of char *memory being a C "string", and first.header_id as well. Then do it this way (omitted everything else to show the important parts):
typedef struct{
unsigned char header_id[5];
} mp3_Header;
char memory[5];
fread(memory, 4, 1, file);
memory[4]='\0';
strncpy(first.header_id, memory, 5)
After the fread, your memory looks like this:
0 1 2 3 4
+----+----+----+----+----+
| T | A | G | + | ? |
+----+----+----+----+----+
The 5th byte, at index 4, is not defined, because you read only 4 bytes. If you use a string function on this string (for example printf("%s\n", memory)); the function doesn't know where to stop, because there is no terminating \0, and printf will continue to output garbage until the next \0 it finds somewhere in your computer's RAM. That's why you do memory[4]='\0' next so it looks like this:
0 1 2 3 4
+----+----+----+----+----+
| T | A | G | + | \0 |
+----+----+----+----+----+
Now, you can use strncpy to copy these 5 bytes to first.header_id. Note you need to copy 5 bytes, not just 4, you want the \0 copied as well.
(In this case, you could use strcpy (without n) as well - it stops at the first \0 it encounters. But these days, to prevent buffer overflows, people seem to agree on not using strcpy at all; instead, always use strncpy and explicitly state the length of the receiving string).
b) You treat memory as binary data, copy the binary data to the header, and then turn the binary data into a string:
typedef struct{
unsigned char header_id[5];
} mp3_Header;
char memory[4];
fread(memory, 4, 1, file);
memcpy(first.header_id, memory, 4)
first.header_id[4]='\0';
In this case, there is never a \0 at the end of memory. So it's sufficient to use a 4-byte-array now. In this case (copying binary data), you don't use strcpy, you use memcpy instead. This copies just the 4 bytes. But now, first.header_id has no end marker, so you have to assign it explicitly. Try drawing images like i did above if it isn't 100% clear to you.
But always remember: if you use operators like '+', you do NOT work upon the string. You work on the single characters. The only way, in C, to work on a string as a whole, is using the str* functions.

Answer 3

Yes, C strings always end in the null (0x00) character. It's the programmer's responsibility to understand that, and code appropriately.
For example, if your header_id will be up to a 3-printable-character string, you need to allocate 4 characters in that array to allow for the trailing null. (And you need to make sure that null is actually present.) Otherwise, printf won't know when to stop, and will keep printing until it finds a 0 byte.

Answer 4

When you copy binary data between buffers you should use appropriate function for the job, like memcpy(). Because you are dealing with binary data you must know exactly the length of the buffer as there is no null characters to indicate the end of data.
To make it a string simply allocate length+1 buffer and set the last byte to '\0' and voila, you have a string. However.. it is possible that there is already a null character in the binary data you copied so you should do some sanity checks before trusting it to really be a string you wanted. Something like \001 might be invalid id for mp3 format.. but it might be a broken file, you never know what you are dealing with.