Signed types for enum tags #2459
Conversation
Certainly at least for |
| } | ||
| bigint_init_bigint(&type_enum_field->value, &proposed_value); | ||
| } | ||
| ErrorMsg *msg = add_node_error(g, field_node, |
There was a problem hiding this comment.
If you make this field_node->data.struct_field.value then the compile error test won't need updated, right? It seems better to point at the value than the field. Likewise with entry->value->data.struct_field.value.
There was a problem hiding this comment.
field_node->data.struct_field.value is null if the user didn't specify it, I've made it point to the field declaration because that's always present.
I can make it choose either of them based on whether value is null or not but I'm not very fond of this "asymmetry" in the error messages.
The C specification mandates the enum to be compatible with signed char, signed int or unsigned int.
Implements #641
The first commit makes sure we produce a valid enum from the C ABI point of view, gcc has a extension where the value can be promoted to
longbut I decided to stick to ANSI C.The
too small to hold all bitscheck is gone, replaced by some simple overflow detection mechanism that's now correct for signed types too.The enumerator value allocation is still starting from 0, no change on that front.
What I found extremely strange is that the value allocation doesn't follow the C semantics where the previous specified value is used as starting point. I can provide a patch to implement this semantic if you wish.