Does structure order matter?

Discussion in 'C Programming' started by Brian Dude, Jan 22, 2006.

  1. Brian Dude

    Brian Dude Guest

    Hello, I've been quite comfortable using linked list for a while now
    without much hassle, but lately I've been getting problems from unexpected
    places. I'm working on a graphing utility program, and to allow multiple
    functions to be entered I figured the best way would be with a linked list:

    struct List{
    int color; /*The color it will be when drawn*/
    int index; /*It's index: Y1, Y2, etc...*/
    char Y[76]; /*The function itself*/
    struct List *prev;
    struct List *next;
    }*current,*first,*hold,*last;

    And I use a switch to process user input...
    (Last is the last node before NULL and hold is a general placeholder)

    switch(r){
    case INSERT: /*When the Insert key is pressed*/
    /*Do some graphics related stuff*/
    /*Add a node to the end of the list*/
    last->next=malloc(sizeof(struct List));
    if(last->next==NULL){
    puts("Cannot allocate function memory.");
    exit(1);
    }
    hold=last;
    last=last->next;
    last->prev=hold;
    last->next=NULL;
    last->color=hold->color+1;
    last->index=hold->index+1;
    /*More graphics stuff*/
    ggets(last->Y,76); /*<-My own string input function*/
    /*More graphics stuff*/
    break;

    From the above, I get errors. Running through the list is fine from first
    to last but from last to first it points to garbage. But I noticed
    everything seems to run fine if I put the:

    last->prev=hold;
    last->next=NULL;

    after the ggets() statement. It's really confusing me as to why. Or is this
    a different problem entirely that I may have overlooked?
    I greatly appreciate any input.

    Brian Dude
     
    Brian Dude, Jan 22, 2006
    #1
    1. Advertising

  2. Brian Dude wrote:

    > Hello, I've been quite comfortable using linked list for a
    > while now without much hassle, but lately I've been getting
    > problems from unexpected places. I'm working on a graphing
    > utility program, and to allow multiple functions to be entered
    > I figured the best way would be with a linked list:
    >
    > struct List{
    > int color; /*The color it will be when drawn*/
    > int index; /*It's index: Y1, Y2, etc...*/
    > char Y[76]; /*The function itself*/
    > struct List *prev;
    > struct List *next;
    > }*current,*first,*hold,*last;
    >
    > And I use a switch to process user input...
    > (Last is the last node before NULL and hold is a general
    > placeholder)
    >
    > switch(r){
    > case INSERT: /*When the Insert key is pressed*/
    > /*Do some graphics related stuff*/
    > /*Add a node to the end of the list*/
    > last->next=malloc(sizeof(struct List));
    > if(last->next==NULL){
    > puts("Cannot allocate function memory.");
    > exit(1);
    > }
    > hold=last;
    > last=last->next;
    > last->prev=hold;
    > last->next=NULL;
    > last->color=hold->color+1;
    > last->index=hold->index+1;
    > /*More graphics stuff*/
    > ggets(last->Y,76); /*<-My own string input function*/
    > /*More graphics stuff*/
    > break;
    >
    > From the above, I get errors. Running through the list is fine
    > from first to last but from last to first it points to
    > garbage. But I noticed everything seems to run fine if I put
    > the:
    >
    > last->prev=hold;
    > last->next=NULL;
    >
    > after the ggets() statement. It's really confusing me as to
    > why. Or is this a different problem entirely that I may have
    > overlooked? I greatly appreciate any input.
    >
    > Brian Dude


    Can it be that your ggets() overruns Y buffer, thus corrupting
    prev and next fields? The fact that it works fine if you repeat
    their initialisation after calling ggets() suggests exactly
    this.

    Cheers

    Vladimir
     
    Vladimir S. Oka, Jan 22, 2006
    #2
    1. Advertising

  3. Brian Dude

    CBFalconer Guest

    Brian Dude wrote:
    >
    > Hello, I've been quite comfortable using linked list for a while
    > now without much hassle, but lately I've been getting problems
    > from unexpected places. I'm working on a graphing utility program,
    > and to allow multiple functions to be entered I figured the best
    > way would be with a linked list:
    >
    > struct List{
    > int color; /*The color it will be when drawn*/
    > int index; /*It's index: Y1, Y2, etc...*/
    > char Y[76]; /*The function itself*/
    > struct List *prev;
    > struct List *next;
    > }*current,*first,*hold,*last;
    >
    > And I use a switch to process user input...
    > (Last is the last node before NULL and hold is a general placeholder)
    >

    .... snip ...
    > /*More graphics stuff*/
    > ggets(last->Y,76); /*<-My own string input function*/
    > /*More graphics stuff*/
    > break;
    >
    > From the above, I get errors. Running through the list is fine
    > from first to last but from last to first it points to garbage.
    > But I noticed everything seems to run fine if I put the:
    >
    > last->prev=hold;
    > last->next=NULL;
    >
    > after the ggets() statement. It's really confusing me as to why.
    > Or is this a different problem entirely that I may have overlooked?
    > I greatly appreciate any input.


    You don't show the ggets code, which is thus highly suspect. I
    suggest you use my ggets, which is freely available (URL below) and
    well tested. It will allocate memory as needed and avoid the
    wastage you are going to get with your declarations above. To use
    it you will declare "char *Y;" in your struct List above.

    <http://cbfalconer.home.att.net/download/ggets.zip>

    which is completely portable and safe. At least nobody has
    reported any bugs to me yet in several years.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
    More details at: <http://cfaj.freeshell.org/google/>
     
    CBFalconer, Jan 22, 2006
    #3
  4. Brian Dude

    Default User Guest

    Brian Dude wrote:


    > From the above, I get errors. Running through the list is fine from
    > first to last but from last to first it points to garbage. But I
    > noticed everything seems to run fine if I put the:




    Please post a complete, minimal, compilable example that demonstrates
    the problem.



    Brian
     
    Default User, Jan 22, 2006
    #4
  5. Brian Dude

    Brian Dude Guest

    D'oh! That's exactly what it was. I just increased the buffer size and put
    those statements back where they were before, and it works fine... Thank
    you!

    > Can it be that your ggets() overruns Y buffer, thus corrupting
    > prev and next fields? The fact that it works fine if you repeat
    > their initialisation after calling ggets() suggests exactly
    > this.
    >
    > Cheers
    >
    > Vladimir
    >
     
    Brian Dude, Jan 23, 2006
    #5
  6. Brian Dude wrote:
    > D'oh! That's exactly what it was. I just increased the buffer size and put
    > those statements back where they were before, and it works fine... Thank
    > you!
    >
    > > Can it be that your ggets() overruns Y buffer, thus corrupting
    > > prev and next fields? The fact that it works fine if you repeat
    > > their initialisation after calling ggets() suggests exactly
    > > this.
    > >
    > > Cheers
    > >
    > > Vladimir
    > >


    Please don't top-post...

    You should probably consider actively checking, and preventing buffer
    overruns in your ggets() (and in general practice, as well). Increasing
    the buffer size is just postponing the inevitable (since you most
    likely can't see into the future...).

    Cheers

    Vladimir
     
    Vladimir S. Oka, Jan 23, 2006
    #6
  7. Brian Dude

    Brian Dude Guest

    I didn't bother to show my ggets() code because my function stands for
    "graphics gets" because it takes input from my programs interface and
    thusly contains some nonstandard code. But it'll be nice to have a decent
    working gets() function!

    CBFalconer <> wrote in article
    <>...
    > You don't show the ggets code, which is thus highly suspect. I
    > suggest you use my ggets, which is freely available (URL below) and
    > well tested. It will allocate memory as needed and avoid the
    > wastage you are going to get with your declarations above. To use
    > it you will declare "char *Y;" in your struct List above.
    >
    > <http://cbfalconer.home.att.net/download/ggets.zip>
    >
    > which is completely portable and safe. At least nobody has
    > reported any bugs to me yet in several years.
    >
    > --
    > "If you want to post a followup via groups.google.com, don't use
    > the broken "Reply" link at the bottom of the article. Click on
    > "show options" at the top of the article, then click on the
    > "Reply" at the bottom of the article headers." - Keith Thompson
    > More details at: <http://cfaj.freeshell.org/google/>
    >
    >
    >
     
    Brian Dude, Jan 23, 2006
    #7
  8. Brian Dude

    CBFalconer Guest

    *** top-posting fixed ***
    Brian Dude wrote:
    > CBFalconer <> wrote in article
    >
    >> You don't show the ggets code, which is thus highly suspect. I
    >> suggest you use my ggets, which is freely available (URL below)
    >> and well tested. It will allocate memory as needed and avoid the
    >> wastage you are going to get with your declarations above. To
    >> use it you will declare "char *Y;" in your struct List above.
    >>
    >> <http://cbfalconer.home.att.net/download/ggets.zip>
    >>
    >> which is completely portable and safe. At least nobody has
    >> reported any bugs to me yet in several years.

    >
    > I didn't bother to show my ggets() code because my function stands
    > for "graphics gets" because it takes input from my programs
    > interface and thusly contains some nonstandard code. But it'll be
    > nice to have a decent working gets() function!


    Please don't top-post. I fixed this one. See the URLs below for
    rationale etc. Top-posting on technical newsgroups is considered a
    sign of ignorance or rudeness.

    http://www.caliburn.nl/topposting.html
    http://www.netmeister.org/news/learn2quote.html
    http://www.catb.org/~esr/faqs/smart-questions.html
    http://www.greenend.org.uk/rjk/2000/06/14/quoting.html
    http://www.i-hate-computers.demon.co.uk/
    http://web.ukonline.co.uk/g.mccaughan/g/remarks/uquote.html

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
    More details at: <http://cfaj.freeshell.org/google/>
     
    CBFalconer, Jan 23, 2006
    #8
  9. Brian Dude

    Brian Dude Guest

    Vladimir S. Oka <> wrote in article
    <>...
    >
    > Please don't top-post...


    sorry...

    >
    > You should probably consider actively checking, and preventing buffer
    > overruns in your ggets() (and in general practice, as well). Increasing
    > the buffer size is just postponing the inevitable (since you most
    > likely can't see into the future...).
    >
    > Cheers
    >
    > Vladimir
    >
    >


    Yes, very good point...
     
    Brian Dude, Jan 24, 2006
    #9
    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. SpaceCowboy
    Replies:
    6
    Views:
    540
    SpaceCowboy
    Aug 14, 2003
  2. hilz
    Replies:
    1
    Views:
    570
    Richard Tobin
    Jan 18, 2006
  3. Mark
    Replies:
    5
    Views:
    593
  4. pete
    Replies:
    20
    Views:
    689
    Richard Bos
    Jun 13, 2005
  5. Replies:
    2
    Views:
    1,595
    Joseph Kesselman
    Aug 10, 2007
Loading...

Share This Page