You are missing my point.
In order to force unsigned right shift on a signed type, you have to cast the
left operand to the corresponding unsigned type, but this cannot be done without
explicit knowledge of said type.
If you want unsigned shift semantics it is unclear to me why you would
have the value stored in a signed type in the first place, certainly with
negative values being a possibility. I would tend to consider this a
non-issue (or at least one not important enough to legislate for at
the language level) until I see a counterexample.
If the type of the left operand later changes
to a different size (char/short/int/long/long long) the cast may go unnoticed
and will produce incorrect results. There is a similar issue when comparing
signed expressions to unsigned ones : you cannot force signed comparison
semantics without explicit casts where the type must be known and maintained.
There are ways to fix this:
It is certainly possible for an unsigned short or unsigned char left
operand to promote to an int. However in that case the value must be
preserved i.e. the result of such a promotion will be non-negative and the
shift operation will produce the same result as if unsigned.
- disallowing unsigned and signed to be used without a size specifier (too
strong)
I don't follow.
- changing the semantics of (signed) and (unsigned) casts to only convert
between compatible types, not assuming int size.
Maybe an example would help.
- adding extra operators such as java's unsigned right shift operator: >>>
Again, an example of where this works where C's existing types and
operators don't would be helpful.
Lawrence
