I think this is desired behavior. GCC compiles this as well, albeit with warnings.
If you don't initialize all values in a struct, the uninitialized values will be their default values (often zero). In your example, you create two structs with only one value given each. SDCC assumes you want to initialize the first value in both cases. { 1 }, for example, results in a struct with a char pointer to 0x1 and an int with the default value, zero.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem is not that it creates the object, but that it does not produce a type mismatch warning. Other patterns always produce the warning. That's a bug in sdcc.
It's even more clearly a bug in sdcc when you consider that
sdcc -mz80 1.c produces no warning
sdcc 1.c produces a warning
sdcc -mds390 /tmp/1.c produces a warning
In fact it seems to be a Z80/Rabbit compiler specific bug ???
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is very much related to the underlying architecture. The mcs51 and ds390 have a Harvard architecture and thus cannot cast an integer constant to a specific memory typed pointer. Is the value 1 pointing to code memory, xdata memory or idata memory? You tell me. They all have an address 1.
The Z80 OTOH is a Von Neumann architecture and thus there is only one address 1. Automatically casting an integer to a pointer is maybe not the best practice, but it is not ambiguous.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think this is desired behavior. GCC compiles this as well, albeit with warnings.
If you don't initialize all values in a struct, the uninitialized values will be their default values (often zero). In your example, you create two structs with only one value given each. SDCC assumes you want to initialize the first value in both cases.
{ 1 }, for example, results in a struct with a char pointer to 0x1 and anintwith the default value, zero.The problem is not that it creates the object, but that it does not produce a type mismatch warning. Other patterns always produce the warning. That's a bug in sdcc.
It's even more clearly a bug in sdcc when you consider that
sdcc -mz80 1.c produces no warning
sdcc 1.c produces a warning
sdcc -mds390 /tmp/1.c produces a warning
In fact it seems to be a Z80/Rabbit compiler specific bug ???
This is very much related to the underlying architecture. The mcs51 and ds390 have a Harvard architecture and thus cannot cast an integer constant to a specific memory typed pointer. Is the value 1 pointing to code memory, xdata memory or idata memory? You tell me. They all have an address 1.
The Z80 OTOH is a Von Neumann architecture and thus there is only one address 1. Automatically casting an integer to a pointer is maybe not the best practice, but it is not ambiguous.