Assigning a non null-terminated string

I'd like to store a string of characters into a character array. This string is intended to be a file format identifier, and would eventually be written to a file. The catch is that in compliance with the file format's specification, this string should not be null-terminated. Here's three different ways I've tried doing it:

Code:

char format_id[4] = 'RIFF';
/* not sure if it's legal.  I get a "multi-character character constant" warning
 * and unintended results */

char format_id[4] = {'R', 'I', 'F', 'F'};
/* this works but is awkward to type and harder to read */

char format_id[4] = "RIFF";
/* works with no compiler complaints, but aren't I assigning a null-terminated string
 * to an array of a smaller size?  It's easy, but feels dirty.  Is this bad form? */

What do you guys do when you need to assign a character string that is not null-terminated?

You can have a null terminated string in your code - but to write only 4 bytes of it into file...
File should be opened in the binary mode - and you probably will use fwrite function for writing

Originally Posted by BattlePanic

Code:

char format_id[4] = "RIFF";
/* works with no compiler complaints, but aren't I assigning a null-terminated string
 * to an array of a smaller size?  It's easy, but feels dirty.  Is this bad form? */

No, it is fine. The compiler recognizes this idiom and leaves the null terminator out.

Originally Posted by vart

You can have a null terminated string in your code - but to write only 4 bytes of it into file...
File should be opened in the binary mode - and you probably will use fwrite function for writing

format_id will actually be a member of a structure that will be written to a file. I'd like to avoid the null character as I'd like the structure's representation in memory to match what it would be on file. This should make writing the entire structure to a file much easier to do.

K&R's ANSI C book seems to suggest that what I'm doing is wrong when stating "It is an error to have too many initializers." (Section 4.9 Initialization) I guess my compiler is just good at guessing what it is that I'm trying to do.

Code:

{'R', 'I', 'F', 'F'};

should be good for any compiler
with the struct to file - be aware of padding...

> I'd like the structure's representation in memory to match what it would be on file.
There's no such guarantee that that will happen.
Padding, data type sizes, alignment and endian-ess all get in the way of simply being able to fwrite a struct to a file and have it recognised as being a file header. You can occasionally persuade the compiler to conform to the first three, but the last will have to be hand coded if you're on a machine with a different endian order to that used by the file.

Elsewhere in K&R, you'll find the case you're looking at is a documented exception.

Originally Posted by Salem

> I'd like the structure's representation in memory to match what it would be on file.
There's no such guarantee that that will happen.
Padding, data type sizes, alignment and endian-ess all get in the way of simply being able to fwrite a struct to a file and have it recognised as being a file header.

Thanks for the tip. I don't have much experience writing data to files. I figured I could use a struct to order the data before committing it to a file with a single fwrite. K&R made me aware of some of the pitfalls but it sounds like it might be a bad practice as its hard to guarantee that things will go as planned.

Given that data type sizes can vary from one platform to another, I'm still not sure how to write code for file output in a portable manner.

Originally Posted by BattlePanic

Given that data type sizes can vary from one platform to another, I'm still not sure how to write code for file output in a portable manner.

using byte array