I refer you to the following code:
It's this:
/*
* structure to access an
* integer in bytes
*/
struct
{
char lobyte;
char hibyte;
};
What's the point? The point is code linke this:
lpr = (tp->t_speeds.hibyte<<10) ...
note how we're treating t_speeds like it's that anon struct above. how's that happen? What's t_speeds?
int t_speeds; /* output+input line speed */
Wait, what? I could just take an int variable, then use an anon struct to break it into bits? Yes, I could. This is C, 1976.
The point is, C changes over time, and so does how you use it. At some point people realized this model was kind of dangerous, and over the objections of many people, the inconvenience of type checking came in. The changes in C are so pervasive that when Dennis checked, years later, the original C compilers ... were no longer C. They would not compile.
The rule over the years is that you should always err in favor of compiler level checking of your code, even when it adds lots of inconvenience, as people make mistakes.
So I would actually be in favor of what paul is advocating, but not the inconistency. To keep it consistent, I don't see that just using 1U everywhere is that huge a deal. C is not that pretty any more, so this little bit of ugliness doesn't strike me as a big deal. Bugs from stuff like 3<<31 scare me more.
Just my $.02
ron