Substructure member list

[frankie]

Great!

[frankie]

Pelle,
as first you made a great job with the new release.
About the memberlist I made some checks with the following:

Code: [Select]

#include <stdio.h>
#include <stdlib.h>

struct ___parts
{
unsigned mantissa:23;
unsigned exponent:8;
unsigned sign:1;
};
typedef struct ___parts T__parts;

union __tst
{
float val;
T__parts parts;
};
typedef union __tst _tst;

union __tst1
{
float val;
struct
{
unsigned mantissa;
unsigned exponent;
unsigned sign;
};
};

union __tst2
{
float val;
struct
{
unsigned mantissa;
unsigned exponent;
unsigned sign;
} parts;
};

union __tst3
{
float val;
struct ___llf
{
unsigned mantissa;
unsigned exponent;
unsigned sign;
   };
};

union __tst4
{
float val;
struct ___llf1
{
unsigned mantissa;
unsigned exponent;
unsigned sign;
   } parts;
};

typedef union __tst1 tst1_typedef;
typedef union __tst2 tst2_typedef;
typedef union __tst3 tst3_typedef;
typedef union __tst4 tst4_typedef;

union __tstArray
{
float val;
struct
{
unsigned mantissa;
unsigned exponent;
unsigned sign;
} parts[10];
} tst10;


int main(int argc, char **argv)
{
union __tst1 tst1;
union __tst2 tst2;
union __tst3 tst3;
union __tst4 tst4;
tst1_typedef tst5;
tst2_typedef tst6;
tst3_typedef tst7;
tst4_typedef tst8;
union __tstArray tst9;
_tst         tst;

tst1.val        = 0.0; //here only member 'val' is found
tst2.parts.sign = 0; //all fields are found!
tst3.val        = 0.0; //here only member 'val' is found
tst4.parts.sign = 0; //here too all fields are found!
tst.val         = 0.0; //in this case the members of parts are not found!
tst5.val        = 0.0; //here only member 'val' is found
tst6.parts.sign = 0; //all fields are found!
tst7.val        = 0.0; //here only member 'val' is found
tst8.parts.sign = 0; //all fields are found!
tst9.parts[1].sign = 0; //all fields are found!
tst10.val        = 0.0; //When the variable is global (outside the scope of a function)
//no member will be found!!!
return 0;
}

As you can see probably some adjustment is still required. In particular if you define a global structure variable (outside scope of any function) the member list don't works. I haven't test with struct pointers (I expect the same behaviour) and limited the check to two levels of structure nesting.

[frankie]

Pelle,
in the meanwhile I tested with pointers to structures, once again if the pointer is a local variable (defined in the function scope) member list works, if it's a global variable the option don't work!

[Pelle]

OK, I will look at it.

Globals have an empty 'text' field right now, so initializing it in the same way as for locals will probably work.

Both globals and locals have a potential problem: I don't attempt to handle the scope, so it's possible to confuse one variable with another. Not sure how common this is - fixing it will be rather complicated, so I would prefer to skip this headache...

Having a struct/union without an identifier (MS specific) is somewhat problematic since I will (again) assign one (possibly fabricated) tag before I know there is no identifier. I might be able to handle it...

Pelle

[Pelle]

The attached version seem to work here - but needs more testing.

Pelle

[frankie]

Pelle,
very good job   .
Now it works with the test that follows, fails only when a typedef'd structure contains another typedef'd structure.

Code: [Select]

#include <stdio.h>
#include <stdlib.h>

struct ___parts
{
unsigned mantissa:23;
unsigned exponent:8;
unsigned sign:1;
};
typedef struct ___parts T__parts;

union __tst
{
float val;
T__parts parts;
};
typedef union __tst _tst;

union __tst1
{
float val;
struct
{
unsigned mantissa;
unsigned exponent;
unsigned sign;
};
};

union __tst2
{
float val;
struct
{
unsigned mantissa;
unsigned exponent;
unsigned sign;
} parts;
};

union __tst3
{
float val;
struct ___llf
{
unsigned mantissa;
unsigned exponent;
unsigned sign;
   };
};

union __tst4
{
float val;
struct ___llf1
{
unsigned mantissa;
unsigned exponent;
unsigned sign;
   } parts;
};

typedef union __tst1 tst1_typedef;
typedef union __tst2 tst2_typedef;
typedef union __tst3 tst3_typedef;
typedef union __tst4 tst4_typedef;

union __tstArray
{
float val;
struct
{
unsigned mantissa;
unsigned exponent;
unsigned sign;
} parts[10];
} tst10;

union __tstArray *tst12;
typedef union __tstArray TypedefTest;

void tst(union __tstArray *passedStruct, _tst *passedStruct2)
{
union __tst1 tst1;
union __tst2 tst2;
union __tst3 tst3;
union __tst4 tst4;
tst1_typedef tst5;
tst2_typedef tst6;
tst3_typedef tst7;
tst4_typedef tst8;
union __tstArray tst9;
union __tstArray *tst11;
TypedefTest typedeftst;
_tst         tst;

tst1.sign           = 0; //OK
tst2.parts.sign     = 0; //OK
tst3.sign           = 0; //OK
tst4.parts.sign     = 0; //OK
tst.val             = 0.0; //still not working
tst5.sign           = 0; //OK
tst6.parts.sign     = 0; //OK
tst7.sign           = 0; //OK
tst8.parts.sign     = 0; //OK
tst9.parts[1].sign  = 0; //OK
tst10.parts[2].sign = 0; //OK

tst11 = &tst10;
tst12 = &tst10;
tst11->parts[2].sign = 0; //OK
tst12->parts[3].sign = 0; //OK

passedStruct->parts[1].sign = 0; //OK
passedStruct2->val = 0.0; // NOT OK!

typedeftst.parts[2].sign = 0; //OK
}

I'll keep you updated about next tests.

[Pelle]

The cases:

Code: [Select]


tst.parts.
passedStruct2->parts.

should work now. It's possible to create an even longer chain of typedef's, that will not work, but I'm not sure it is very common. This will in any case slow things down enough to make it nearly useless. To handle most practical cases, rather than every theoretical case, is probably enough for now...

Have you found anything else not working...?

Pelle

[frankie]

Pelle,
I made the following further tests (code added to the previous posted test):

Code: [Select]

typedef unsigned _NewType;

union __tst02
{
float val;
struct ___parts;
_NewType NewType;
};

union __tst03
{
float val;
struct ___parts parts;
_NewType NewType;
};

typedef union __tst03 _tst03;

.... .... .... .... .... ....

void tst(union __tstArray *passedStruct, _tst *passedStruct2)
{
union __tst1 tst1;
union __tst2 tst2;
union __tst3 tst3;
union __tst4 tst4;
tst1_typedef tst5;
tst2_typedef tst6;
tst3_typedef tst7;
tst4_typedef tst8;
union __tstArray tst9;
union __tstArray *tst11;
TypedefTest typedeftst;
_tst         tst;
union __tst  tst01;
union __tst02 tst02;
union __tst03 tst03;
_tst03 TypeDeftst03;

tst1.sign           = 0; //OK
tst2.parts.sign     = 0; //OK
tst3.sign           = 0; //OK
tst4.parts.sign     = 0; //OK
tst.val             = 0.0; //still not working (members of parts not found)
tst5.sign           = 0; //OK
tst6.parts.sign     = 0; //OK
tst7.sign           = 0; //OK
tst8.parts.sign     = 0; //OK
tst9.parts[1].sign  = 0; //OK
tst10.parts[2].sign = 0; //OK

tst11 = &tst10;
tst12 = &tst10;
tst11->parts[2].sign = 0; //OK
tst12->parts[3].sign = 0; //OK

passedStruct->parts[1].sign = 0; //OK
passedStruct2->parts.sign = 0; // NOT OK! (members of parts not found)

typedeftst.parts[2].sign = 0; //OK

tst01.parts.sign = 0; //NOT OK (members of parts not found)
tst02.NewType = 0; //OK
tst03.parts.sign = 0; //OK
TypeDeftst03.parts.sign = 0;//OK
}

Definitely the browser is not working when a typedef'd structure is inserted in another structure. With typedef'd basic variables (as the freshly added NewType) it still works.
Everything works fine if the tag name is used.

[frankie]

Pelle,
I made other checks, and fund that memberlist doesn't work if an inner structure is contained in a header file not directly included by the c file. This means that access to substructure members defined ia a header included by another header are not accessible.
Anyway I immagine that this is already known (becouse actually you don't scan included files).

[Pelle]

Yes, pobr will never scan #include files directly. When building a project, I try to add all dependent files (even #include files) for scanning. This require that the dependency information is up-to-date - "Update all dependencies" is important here...

I also can't see how it can be useful to reference fields from a definition that isn't included - sounds like it should be hard to compile... ;-)

Pelle

[frankie]

Pelle I mean **not directly included** not not included at all, i.e.:

Code: [Select]

FILE MAIN.C:
#include "definitions.h"

.... ... ....
CODE
... ... ... ...

END of MAIN.C

FILE DEFINITIONS.H:
#include "structs.h"
#include "variables.h"
... ... ... ... ...
END of DEFINITIONS.H

In this case with cascade includes normally memberlist doesn't work.

But anyway Pelle it is very functional now (and sufficient for my uses  :wink: ).
So I think it's OK  :mrgreen: .
F.

[Pelle]

Pelle I mean **not directly included** not not included at all...

Ah! OK.

In this case with cascade includes normally memberlist doesn't work.

No, probably not.

But anyway Pelle it is very functional now (and sufficient for my uses  :wink: ).
So I think it's OK  :mrgreen: .
F.

It should work OK now - especially with recent changes.

This will however not work perfectly anymore:

Code: [Select]


union __tst3
{
   float val;
   struct ___llf
   {
      unsigned mantissa;
      unsigned exponent;
      unsigned sign;
   };
};

With an existing tag ('___llf') I can't assign it's members to tag '__tst3' - so they will not show up in the list. No way to solve this, but I'm not sure it's a big problem in real world code.

Pelle

[frankie]

Pelle,
just for sake of curiosity, you wrote:

With an existing tag ('___llf') I can't assign it's members to tag '__tst3' - so they will not show up in the list.

this seems something like a down-top approach, but could eventually be more functional a top-down approach where you store in main structure record the reference to the included structures? So when you have a symbol that is a structure you have also, in the symbol's record, the tags of all other symbols and structures accessed. This means that, becouse of recursion, you have to modify the main struct record as many times as many symbols it includes. Not easy, but not a complete nightmare.
Anyway you made a great job.

[Pelle]

It might help in this special case, but otherwise not very useful I think.

More redundant info in the database, making it bigger. Not much help during lookup either - I still have to resolve typedef's, since this info might not be available when building the browse info (not in the current file).

Pelle

[frankie]

I see.
Anyway I think that the occourrence of a tag to an unnamed substructure inside a structure is more unique than rare  :mrgreen: . And this kind of definition is not a good practice, for me it's martian code  :lol: .
Thank you for the answer.