Set the first byte to 0 or use memset to "reset" entire buffer

Question

In C programming, whenever I try to perform first time cat, I need to

TCHAR file_name[1024];
// Use memset or set the first byte to 0?
file_name[0] = 0;
_tcscat(file_name, TEMP_DIRECTORY_PATH);
_tcscat(file_name, file);

I see most programmers are using memset. But, for me, I just set the first byte to 0, to let _tcscat knows where to start from.

I am not sure whether there is any shortcoming / trap for doing so, instead of using memset?

Thanks.

Answer 1

I disagree with most of the answers that seem to indicate that setting the entire buffer to 0 may be helpful. If you're copying/concatenating null-terminated strings into the buffer, there's no need to clear the whole thing - it seems to me to be a waste (though it certainly might be a waste that's not worth worrying about).

You might take the approach that Artelius suggested and use a strcpy() variant to get the initial string into the buffer, but I think the symmetry of your approach using strcat()` has merit as well (though I think that just setting the 1st character to 0 is enough).

As an aside, if the buffer might contain 'sensitve' data (password info or something) - that might be reason to clear the whole thing. But if that's the case, take a look at http://msdn.microsoft.com/en-us/library/ms972826 for some reasons why memset() might not be quite enough.

Answer 2

You can just set the first char to 0.

However an even easier way would be to

TCHAR file_name[1024];
_tcsncpy(file_name, TEMP_DIRECTORY_PATH, 1024);
_tcscat(file_name, file);

Answer 3

None really, other than that setting everything to nulls can prevent bugs later, i.e. if you don't add one for some reason. It's easier to fill the entire string with zeros and know that you don't have to worry about adding a null terminator on manually later so long as you don't overflow the buffer.

Answer 4

Setting the entire buffer to NUL characters is a "defense in depth." Such a defense covers for a mistake made elsewhere in the source code, perhaps by a different programmer. In this case, the mistake guarded against would be copying a string which does fit the buffer, but not copying the NUL termination byte. The already-zero'd buffer would provide terminating NULs for this mistaken string copy to "use." Programmers differ on the wisdom of "Defense in Depth" because such coding can mask programming errors which are allowed then to fester in the source code -- being fixed only long after they are introduced.

In my personal opinion, setting the buffer to all NUL characters like this as a "defense in depth" is a huge waste. It would make more sense to only NUL the final byte. Then errors would show through but strings would eventually be terminated. Once you start going down that path of thought, the "defense in depth" would make more sense if the buffer were made two machine words longer, and those words were zero-ed out, and possible a canary value could report an overrun of the buffer, and....

Or you could just not overrun buffers, and write your program so that it crashes as quickly as possible if you do. That's what I like to do.