Where is the value getting initalized in this case

[Chad]

In the following code snippet, the value of 'lin' is someone gettng
intialized to the value of 1.

int main(argc, argv)
int argc;
char **argv;
{
int err, tflg = 0, wflg = 0, slen, wr,
sum = 0, in, rflg = 0, i, j, lin, waiting = 0;
char str[256];

memset(str, '\t', sizeof (str));

slen = sizeof (str);

while ((err = getopt(argc, argv, "t:s:wrp:")) != -1)
switch (err) {
case 't':
tflg = 1;
strncpy(tsk[0].u.ut_line, optarg, sizeof
(tsk[0].u.ut_line));
break;

case 's':
strncpy(str, optarg, sizeof (str));
slen = strlen(str);
break;

case 'w':
wflg = 1;
break;

case 'r':
rflg = 1;
break;

case 'p':
#ifndef BSD
fprintf (stderr, "warn: this feature isn't
available"
"under this OS\n");
exit (1);
#endif
ptitle (optarg);
break;

case '?':

default :
usage();
}
argc -= optind;
argv += optind;

There is no other place were the value of 'lin' is used. Later on in
main(), the author starts to compare the value of 'lin'. This is what
struck my curiosity in the first place. It appears that he was
comparing the unitialized value of 'lin' to numbers.

However, when i step throug the debugger, I see the following:
Breakpoint 1, main (argc=4, argv=0xcfbdafac) at no.c:243
243 {
(gdb) display lin
1: lin = -809652604
(gdb) step

Breakpoint 2, main (argc=4, argv=0xcfbdafac) at no.c:244
244 int err, tflg = 0, wflg = 0, slen, wr,
1: lin = 1

Is there somewhere else I should try to look in the program? Or is
this just possibly undefined behavior?



Chad

 

[CBFalconer]

In the following code snippet, the value of 'lin' is someone gettng
intialized to the value of 1.

int main(argc, argv)
int argc;
char **argv;
{
int err, tflg = 0, wflg = 0, slen, wr,
sum = 0, in, rflg = 0, i, j, lin, waiting = 0;
char str[256];

memset(str, '\t', sizeof (str));
slen = sizeof (str);

str has no terminating '\0' char. slen will also be high by one.

Why don't you use modern organization of the functions? i.e.:

int main(int argc, char **argv) {

The K&R1 style hasn't been used for almost 20 years.

 

[Charlie Gordon]

In the following code snippet, the value of 'lin' is someone gettng
intialized to the value of 1.

int main(argc, argv)
int argc;
char **argv;
{
int err, tflg = 0, wflg = 0, slen, wr,
sum = 0, in, rflg = 0, i, j, lin, waiting = 0;
char str[256];

memset(str, '\t', sizeof (str));

not enough code is provided, but it is ill advised to initialize an array
called 'str' to something that is not a C string.

slen = sizeof (str);

calling a size 'slen' is bad omen.

while ((err = getopt(argc, argv, "t:s:wrp:")) != -1)
switch (err) {
case 't':
tflg = 1;
strncpy(tsk[0].u.ut_line, optarg, sizeof
(tsk[0].u.ut_line));

strncpy is most likely misused here, but we need more information to verify.

break;

case 's':
strncpy(str, optarg, sizeof (str));
slen = strlen(str);

strncpy *is* misused here: strlen will invoke undefined behaviour if -s is
given a long enough argument.

don't use strncpy!

break;

case 'w':
wflg = 1;
break;

case 'r':
rflg = 1;
break;

case 'p':
#ifndef BSD
fprintf (stderr, "warn: this feature isn't
available"
"under this OS\n");
exit (1);
#endif
ptitle (optarg);
break;

case '?':

default :
usage();
}
argc -= optind;
argv += optind;

There is no other place were the value of 'lin' is used. Later on in
main(), the author starts to compare the value of 'lin'. This is what
struck my curiosity in the first place. It appears that he was
comparing the unitialized value of 'lin' to numbers.

undefined behaviour is invoked then.
a good compiler should detect that.

However, when i step throug the debugger, I see the following:
Breakpoint 1, main (argc=4, argv=0xcfbdafac) at no.c:243
243 {
(gdb) display lin
1: lin = -809652604
(gdb) step

Breakpoint 2, main (argc=4, argv=0xcfbdafac) at no.c:244
244 int err, tflg = 0, wflg = 0, slen, wr,
1: lin = 1

Is there somewhere else I should try to look in the program? Or is
this just possibly undefined behavior?

actually, it looks like a side effect of the way gdb works: local variables
are not yet addressable at the first breakpoint, presumably because the
stack frame has not been set up yet. gdb should not even display a value
for lin, it uses whatever value is current for the stack frame pointer. On
the second breakpoint, the stack frame pointer has been set up, gdb displays
the contents of the location where lin will be stored (or at least read
from) at some later point in the program. It happens to contain 1, but this
is just a coincidence, it may contain something else on another invocation,
or on a different architecture.