Myles Watson wrote:
On Wed, Mar 17, 2010 at 6:17 PM, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net mailto:c-d.hailfinger.devel.2006@gmx.net> wrote:
Hi Segher, you're probably able to solve this one easily. On 18.03.2010 00:45, Myles Watson wrote: >>> -extern unsigned char AmlCode[]; >>> +extern void* AmlCode; >>> >>> >>> So AmlCode is used as a void * pointing to the address 0x54445344 >> What is it, you want to do? >> >> > Get rid of the type punned warning that gcc gives for that code where > AmlCode gets cast to acpi_header_t. > Could __attribute__((may_alias)) help?
I'd rather not use an attribute if we can just use a cast.
It seems to work to have an intermediate void*:
void_ptr = &AmlCode_ssdt; current += ((acpi_header_t *)void_ptr)->length;
It compiles without warning and is functionally correct, but it may be too ugly. I'm still surprised that it needs to be &AmlCode_ssdt. I really expected Amlcode_ssdt to be a cast-able pointer.
If you have this in one C file:
static const char AmlCode[] = {0,1,2,3,4,5,6,7};
You can then have this in another C file, which is what you want:
struct AmlCode_s { /* stuff ? */ int a, b; };
extern const struct AmlCode_s AmlCode;
This will mean that you've got wrong debug info, of course, but it is what you seem to want. The first file defines a symbol, and the second files says that a symbol is defined somewhere else. The types don't match, but the C compiler doesn't know / care about that.
(Image what would happen if you were to replace the first file with assembler.)
I'm not sure I like this solution.
MM