char x [1000];
x = 'hello';
.....
clear contents of x???
What would i use to clear x? I'm not able to re-initialise it, use strcpy(x, '/0') or free().
+2
A:
Usage of free() would be wrong, since x is in the stack.
What do you mean by clear? Set it to a default value? Can you use memset? (I'm copying your code as it is)
#define CLEAR(x) memset(x,'\0',1000)
char x[1000];
x= 'hello';
CLEAR(x)
If not, you can always use a for loop.
Tom
2010-09-30 13:57:31
Many thanks Tom, memset did the trick :)
Kay
2010-09-30 13:59:34
A:
If by "clear" you mean "clear all bits in the array", how about memset(x, '\0', 1000);?
Ken
2010-09-30 13:58:04
+1
A:
x='hello';
may not be doing what you expect because ' denotes a character constant (or in this case a multi-character constant) not a string.
In fact, gcc won't accept the above code, complaining that 'hello' is to long (that's on a machine with 4 byte ints), and that x = 'hell' is an incompatible assignment because a char[] is not the same as an int.
Nor should
char x[1000];
x="hello";
work because you can't assign arrays that way.
dmckee
2010-09-30 14:06:36
+3
A:
You cannot assign anything to an array, which your variable x is. So therefore anything that starts with x = is wrong. Secondly 'hello' is not a string, it is a multicharacter literal which is of type int, so this doesn’t make sense either. A string literal is enclosed by " while character (or multicharacter) literals are enclosed by '.
So if you want to fill your buffer x with the string "hello" you use strncpy or even better strlcpy if available:
strncpy( x, "hello", sizeof( x ) );
strlcpy( x, "hello", sizeof( x ) );
The strlcpy function is better because it always terminates the string with a nul character.
If you want to clear it you could do what the other answers suggested. I’d suggest using strncpy or strlcpy with an empty string as @codaddict suggested. That is the code that says most obviously "hey, I want to clear that string". If you want to remove the whole contents of the string from memory (for example if it contained a password or something like this) use memset as @Ken and @Tom suggested.
Also note that you never ever use functions like strcpy or strcat that don’t accept the size of the output buffer as a parameter. These are really not secure and cause nasty bugs and security vulnerabilities. Don’t even use them if you know that nothing can go wrong, just make a habit of using the secure functions.
Sven
2010-09-30 14:16:11
If you're too dumb to use `strcpy` (which most of us are most of the time), don't use `strlcpy` or `strncpy` either. You'll still mess it up, either because you'll pass in the wrong size for some allocated buffer, or because your program will fail to account properly for string truncation, or both. Instead, use a third-party string library, or better still a different language.
Steve Jessop
2010-09-30 14:54:36
@Steve: there is no right way to use `strcpy`. But `strncpy` and especially `strlcpy` are all right. If someone can’t even get the buffer size to pass in right they shouldn’t be programming at all. The only problem left is that `strncpy` leaves the `nul` terminator out if there is not enough space in the buffer. That’s why I recommend `strlcpy` which always adds the ternimator. True, these might truncate strings but that’s hardly a problem at all compared with buffer overruns. Using a third party string library is a good idea, but one still should know about the problems with plain C strings.
Sven
2010-09-30 17:18:06
"there is no right way to use strcpy" - yes, there is. You need to know two numbers, and that one is bigger than the other. Meanwhile, assuming that string truncation won't cause problems, perhaps including serious security problems, is very nearly as irresponsible as using `strcpy` when you don't know how to do so correctly. Simple example: for serious security reasons to do with authentication or permissions, you need to check whether string A is a prefix of string B, but in the process of constructing string A you truncate it? That's as much a potential ownage as a buffer overrun.
Steve Jessop
2010-09-30 21:55:19
Anyway, I don't say you shouldn't use strlcpy in preference to strcpy, if it's available. My point is that even if you're not going to use strcpy, you still need to be smart enough (or to be more precise, diligent enough) to use it, or you will make other equally damaging mistakes, fairly frequently. It's much better to be smart, than it is to be told a bunch of rules like "never use strcpy". I agree with you that some people are too slipshod to be allowed to program C, I just disagree what the threshold is. If strlcpy is saving someone from overruns, they're failing the threshold.
Steve Jessop
2010-09-30 22:09:35
Of course, all that said, the raw number of security-flaw bugs found which involve overruns is greater by far than the number found which involve unexpected string truncation. It's not clear how those numbers change when more muppets start using strlcpy in preference to strcpy ;-) And I'd much rather rely on code written by someone who cares deeply about buffer sizes, because they've used strcpy correctly in the past, than code written by someone who has been told that strlcpy is "secure". Even if both of them end up using strlcpy, one has a clue.
Steve Jessop
2010-09-30 22:10:22
I see what you mean. If string truncation is a big deal one of course has to do some more checks. Creating a buffer overrun is *always* a security problem, string truncation is often not. But checking the length of a string every time so one can use plain `strcpy` instead of `strlcpy` is stupid IMHO. I’d use `strlcpy` even if I knew that the buffer is large enough to hold the string and I could get away with `strcpy`.
Sven
2010-09-30 22:35:15