Messages in this thread | | | Date | Tue, 29 Feb 2000 12:51:56 -0800 | From | David Schleef <> | Subject | Re: string-486.h? |
| |
On Tue, Feb 29, 2000 at 11:20:25AM -0600, Bill Wendling wrote: > Also sprach Ben Kosse: > } > Well the problem is bad 'C' code. It's not the compiler's fault. It's > } > just doing what it's told to do. > } > > } > char str[12]="mystring"; > } > > } > declares a string on the stack with room for 12 bytes. However it is > } > initialized with only 9 (8 characters + the implied \0). So the rest > } > of the area has to be zeroed, which the compiler does. > } No it doesn't. For all C is required to care about, it could be stored as: > } "mystring\0bla" The definition is 12 bytes on the stack, the first nine being > } "mystring\0". > } > Depends on where the char str[12] is placed. If it is global, then it is > zeroed cause it's static...If it's an auto, then it can (and probably > does) have garbage after the terminating \0. >
The problem is that "mystring" is a null-terminated ASCII string and char str[12] is an array of 12 chars, not an ASCII string. One of the arguable aspects of C is that _all_ elements get initialized in an array. It is similar to
{ int zeros[10]={ 0 }; struct { int foo; int bar; }x = { 1 }; }
In both cases, the entire array or structure has to be cleared. As Richard said above, "the problem is bad 'C' code." Personally, I think that auto-initialization of auto variables is a nasty feature, and I try to avoid using it in my own code in cases where it is inequivalent to initialization of global variables.
dave...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |