Where is the value getting initialized 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 somehow 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. Advertisements

  2. This is wrong. After filling str with 256 tabs it is not a string (no
    null) so strlen(str) is an error.
    This may be OK provided you don't assume tsk[0].u.ut_line is a string.
    This code is wrong, though it may not be going wrong in any particular
    execution of the program -- unlike the memset/strlen problem above
    which always provokes undefined behaviour.

    A small, complete example of the problem would be more useful than a
    fragment and some debugger output -- and in trying to make such an
    example you will often find the problem yourself.
     
    Ben Bacarisse, Sep 18, 2007
    #2
    1. Advertisements

  3. Ben Bacarisse said:
    That doesn't look like strlen to me.
     
    Richard Heathfield, Sep 18, 2007
    #3
  4. Not to me, now. I have no idea what I was thinking! It it slightly
    peculiar code, but not actually wrong.
     
    Ben Bacarisse, Sep 18, 2007
    #4
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.