On Thu, 3 Oct 2019, Joe Forster/STA wrote:
Hi David,
Error src\common\fastmem.c 160: Ambiguous member name 'flags' in function
restart_header
I could reproduce this with Turbo C 3.00 running in DOSBox. It's not a
compiler bug.
If you read the help page of the error message, it applies to
_assembly_code_, in the body of the SET_WORD macro. If multiple structs have
a member with the same name, you have to qualify the member name with the
struct name - but only in assembly code.
Assemblers don't know much about types. They cannot deduce from the
expression "z_header.flags" that to the right of the dot is the "flags"
member specifically of the type of the "z_header" variable (on the left),
"z_header_t", they rather translate this to a general expression like
"address(z_header) + member_offset(flags)" for which the member's offset must
be unambigious.
You can narrow down the problem by inserting this line just below line 160:
asm mov ax, z_header.flags;
and you'll get the same error for this line, too.
Actually, I think, the help page is wrong about the qualification syntax. You
have to change line 160 like this:
SET_WORD(H_FLAGS, z_header.(z_header_t)flags);
or
SET_WORD(H_FLAGS, z_header.(struct zcode_header_struct)flags);
That is, there is no dot between the type qualifier and the member name. Have
fun,
How did this work? I used
SET_WORD(H_FLAGS, z_header.(struct zcode_header_struct)flags);
and I got this:
Error src\common\fastmem.c 160: Invalid combination of opcode and operands
in function restart_head
--
David Griffith
[email protected]
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
