Typedef ordering issue.

[Kneesnap]

Typedefs don't appear to work the way which they do in GCC (In games from the PS1/N64 era).

// 1.
typedef struct __cav_web_vertex			CAV_WEB_VERTEX;

// 2.
struct __cav_web_lines
	{
	CAV_WEB_VERTEX	we_line_1;
	CAV_WEB_VERTEX	we_line_2;
	};	

// 3.
struct __cav_web_vertex
	{
	MR_SHORT		we_vertex_x;
	MR_SHORT		we_vertex_y;
	MR_SHORT		we_vertex_z;
	MR_SHORT		we_pad;
	}; 

Yields this message in mips_to_c:

Tried to use struct __cav_web_vertex before it is defined (does it have a definition?).

Yet, this code is valid, compiles, and functions properly with cc1psx (GCC).

I'm hoping this can be fixed so such syntax does work, it makes decomping games with partial source code significantly easier.

[zbanks]

You're right that mips_to_c is stricter about the ordering of struct definitions than most compilers are.
Presently, mips_to_c evaluates struct/union definitions in a single pass to determine their sizes.

In the example you gave, swapping sections 2 & 3 would fix the issues. Notably, it's always possible to reorder a (valid) C file to get something that mips_to_c will accept.

Here's a smaller set of test cases that demonstrate the difference between mips_to_c and "standard C" (without using any typedefs):

// Valid C, and also allowed by mips_to_c 
struct foo { struct bar *x; };
struct bar { struct foo y; };

// Valid C, not allowed by mips_to_c 
struct foo { struct bar x; };
struct bar { struct foo *y; };

// Neither valid C, nor allowed by mips_to_c
struct foo { struct bar x; };
struct bar { struct foo y; };

It would be possible to fix this in mips_to_c, at the cost of added complexity -- until now we haven't really seen many projects where this has been necessary though?

[Kneesnap]

Hmm, unfortunately there are at least 3 projects I'm working on (long term) which would benefit from this, which I'd like to be able to use automated tooling to create context which mips_to_c can understand, as I'm doing here. While it's not that difficult to manually individual occurances of this manually.

It's possible I don't understand the scope of work that this feature would require for mips_to_c, but I suspect it is less work than for me to automatically export it this way, and would be a better outcome overall.