Curently SDCC is one of the few C implementations in which bit-fields
are unsigned, unless explicitly signed. I.e.
struct s
{
int i : 3; // This is an unsigned bit-field
unsigned int u : 3; // This is an unsigned bit-field
signed int s : 3; // This is a singed bit-field
};
On one hand, there is an explicit permission in the C standard for plain
bit-fields to be unsigned. On the other hand: this is the only place
where signed int is different from int, and it is unclear how exactly to
handle this in more complex cases, and it is getting worse in recent C
standards.
typedef int ti;
signed short s;
struct s
{
ti i : 3; // This is an unsigned bit-field in SDCC
typeof (1) j : 3; // Is this unsigned?
typeof (+s) k : 3; // Is this unsigned?
};
A typedef creates another name for a type, and signed int is the same
type as int, but despite there formally being no other information than
the type, for SDCC is currently still makes a difference once that
typedef name is used for a bit-field. And I didn't even check the typeof
examples in SDCC. Formally, 1 is a int according to the section on
decimal inteegr literals in the C standard, but he text just below calls
it a "signed type". s is a signed short, but due to integer promotion,
+s is of type int.
I don't really see a good solution here. And so far the standard
comittee hasn't come up with one either. Personally, I think there is no
good way out that keeps int bit-fields an unsigned.
Do SDCC users have a preference? If yes, why?
Do any SDCC users currently rely on "plain int" (either directly, via
typedef or typeof) bit-fields being unsigned in SDCC? How much would it
inconvenience you if the next version of SDCC made "plain int"
bit-fields signed?
Philipp
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
