Reviving an Old Aztec C program and problems

A defs.h has the following:

struct allomorph {
char *rest_key;
char conds[2];

union {
char *morphname;
struct SD_affix *morpheme;
} dp;
struct allomorph *alink;
};

struct SD_affix {
char *morphname;
char category[8];
unsigned props;
};

struct amlist {
struct allomorph *amp;
int alen; /* length of allomorph string */
struct amlist *amlink;
};



I'm having a problem with scope. Example:

foo()

{

struct allomorph *al;

al->alink->dp.morpheme->category[1] = '\0'; // bad access, out of scope



}


After this struct allomorph is declared, I find that category[] elements in the second line are out of scope. Perhaps this is a result of the evolving of the c language to C++ and that older compilers could compile this and all of the possible members would be in scope. Any input appreciated. Since conds[] are out of scope it fails to compile complaining about being out of scope.

Thanks
Is there a different al local variable in the same function?
For example,
1
2
3
4
5
6
int a; //a_0
a=10; //refers to 'a_0'
{
    int a; //a_1
    a=10; //refers to 'a_1'
}
Sorry, I should have put the actual code up. Here are the actual declarations and the line that complains. I had left the declaration of TRIE out also which no doubt plays a role.

struct TRIE {
char *letters; /* string of letters at this node */
struct TRIE *subtries; /* pointer to linked list of subtries */
struct TRIE *tlink; / * link in list of subtries */
struct allomorph *amorphs; /* pointer to linked list of allomorphs */
};

struct allomorph {
char *rest_key;
char conds[2];

union {
char *morphname;
struct SD_affix *morpheme;
} dp;
struct allomorph *alink;
};

struct SD_affix {
char *morphname;
char category[8];
unsigned props;
};

struct amlist {
struct allomorph *amp;
int alen; /* length of allomorph string */
struct amlist *amlink;
};


foo(dict)
struct TRIE dict*;
{
struct amlist *lp;
struct amlist *pfxlist;
struct allomorph *ap;


for (lp = pfxlist, ap = pfxlist->amp; lp; lp = lp->amlink, ap = lp->amp) // complains here "out of scope"

}

pfxlist, lp, and ap all have elements out of scope. Thanks again.

Last edited on
Can you please post the exact error message.

This compiles fine in VS2005 once the signature is update, a comma is put in the loop and the comment on line 5 is fixed.
Last edited on
kbw,

It compiles ok. Always has, guess that was misleading. Sorry!

Where I am having the problem with scope (I presume) is when executing.

I get: GDB: Program Received Signal : "EXC_BAD_ACESS" and the execution stops.

Checking the variables I can tell that conds[] is always "out of scope" in any amlist referenced by lp. pfxlist and ap seem to be fine. The routine is working with data from the struct TRIE. I can't understand why pfxlist and ap point to amlist with all referenced variables in scope and lp points same amlist and the same variables are "out of scope". This code ran fine in a UNIX type environment back in late 80's and was all C code.

FYI I am using Xcode and it is compiled as a UNIX command line tool.


Mmm, it's not possible to tell from what you've posted. Presumably there's code that initialises pfxlist before the loop.
To remove all other influence, I created a new project with one file, it compiles ok but still has EXC_BAD_ACCESS on one line. I removed the for statement to see which statement was causing the problem and still don't understand why!! There is nothing else to influence the code below.



struct allomorph {
char *rest_key;
char conds[2];
union {
char *morphname;
struct SD_affix *morpheme;
} dp;
struct allomorph *alink;
};

struct SD_affix {
char *morphname;
char category[8];
unsigned props;
};

struct amlist {
struct allomorph *amp;
int alen;
struct amlist *amlink;
};


int main()
{
struct amlist *lp;
struct amlist *pfxlist;
struct allomorph *ap;

lp = pfxlist;
ap = pfxlist->amp;
lp = lp->amlink;
ap = lp->amp; // fails on execution here EXC_BAD_ACCESS, what's wrong with this line????

return(0);
}
pfxlist is uninitialised, then it's used to initialise other values and dereferenced. I'm surprised it didn't crash on ap = pfxlist->amp
Thanks kbw,

This helps me think through the process. pfxlist in the full code is suppose to be initialized by calling another routine. Now I need to look at that routine to see why it does not return anything.
Topic archived. No new replies allowed.