Does structure order matter?

[Brian Dude]

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

 

[Vladimir S. Oka]

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

 

[CBFalconer]

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/>

 

[Default User]

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

 

[Brian Dude]

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!

 

[Vladimir S. Oka]

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!

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

 

[Brian Dude]

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]

*** top-posting fixed ***

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/>

 

[Brian Dude]

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...