Michal,
> Thank you for the response. I thought that a compiler takes care
> about appending \0 at the end of the string.
Please check ANSI C specification. Compiler takes care about appending \0 only
with following cases.
char c1[2]; // global variable
void f() {
char c2[2]="a"; //initialized with quoted string with SIZE-1 or less length
}
On the other hand, following cases, compiler does not take care about appendin
g
\0.
void f() {
char c3[2]; //local variable without initialization
char c4[2]="ab"; // initialized with quoted string with SIZE length
printf("%s %s\n",c3,c4); //Cause unrepeatable problem
}
This is the C/C++ specification. Reason for not initializing local variable
is run-time speed. It is easy to initialize local variable too with some cost
of run-time efficiency. Cint complies to the C/C++ standard here so does the
gcc.
> This happens inside
> getfloats when I compile the program in question with gcc and run it
> under debugger.
It is just coincidence. That memory area happens to be 0 when you ran it with
gcc. If you link other program or do something else and call the function
again , gcc can cause the same problem too.
Please note that no existing C/C++ compiler appends \0 in this case.
You have to explicitly assign 'cc[1]=0;' in getfloats.
int getfloats() {
char cc[2];
cc[1]=0; // THIS MUST BE ADDED
.
.
}
> I don't know how to use cint debugging facilities, so I cannot tell
> you what happens under root.
> Why do I get no segmentation violation when I replace a call to
> a function in the main macro by the getfloats code if there is
> a problem with a non-initialized local variable?
This is coincidence too. In this case, the memory area you got happend
to be 0. Further, your original program run without problem on CINT in my
machine but this is also just a coincidence.
Masaharu Goto
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:28 MET