Where is the value getting initalized in this case

Discussion in 'C Programming' started by Chad, Sep 18, 2007.

  1. Chad

    Chad Guest

    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
     
    Chad, Sep 18, 2007
    #1
    1. Advertising

  2. Chad

    CBFalconer Guest

    Chad wrote:
    >
    > 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.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Sep 18, 2007
    #2
    1. Advertising

  3. "Chad" <> a écrit dans le message de news:
    ...
    > 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.

    --
    Chqrlie.
     
    Charlie Gordon, Sep 18, 2007
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steve Franks
    Replies:
    2
    Views:
    1,257
    Steve Franks
    Jun 10, 2004
  2. Tee
    Replies:
    3
    Views:
    7,817
    Herfried K. Wagner [MVP]
    Jun 23, 2004
  3. Janice

    lower case to upper case

    Janice, Dec 10, 2004, in forum: C Programming
    Replies:
    17
    Views:
    1,182
    Richard Bos
    Dec 14, 2004
  4. mhshpk
    Replies:
    0
    Views:
    314
    mhshpk
    Aug 30, 2007
  5. Chad
    Replies:
    3
    Views:
    379
    Ben Bacarisse
    Sep 18, 2007
Loading...

Share This Page