| [Moved back to tech-toolchain]
|
| On Sat, 28 Jul 2001, Christos Zoulas wrote:
|
| : | Huh?  Unless you have a specific counterexample, all cases where the
| : | compiler is warning about type conversion portability problems are perfectly
| : | correct in their assertions.
| :
| : It is a PITA to change int's in structures to size_t's, or cast every use
| : of them.
|
| If the struct member really is "int", you have to cast it anyway -- you lose
| signedness if you try to autoconvert it to size_t (which is unsigned).  This
| is required.
|
| If the struct member is "unsigned [int]", you shouldn't have to cast it, as
| the autoconversion rules in C99 will let this be promoted to "unsigned long"
| (where that is the type of size_t) without a warning.

OTOH, if you assign a size_t to that member, on some platforms you need
to cast it since size_t is unsigned long and you lose precision, and on
others (most) you don't.  The problem is that most people are running
machines in the latter category and do not get warnings when they fail
to add the correct casts that are required on 64-bit platforms.

| Welcome to code portability.  (You did write that in the new bylaws as a
| goal, right?  This is tongue-in-cheek, mind you, not meant as a jab.  8-)

So large numbers of people check in buggy code and don't notice, while
those of us on real machines need to go back and clean up the mess.

| : | : It is a problem when you have an int that you are passing in a size_t
| : | : parameter argument. consider:
| : | :
| : | :     strncpy(foo, bar, 13);
| : | :
| : | : Well, is that 13U or 13UL? Or should I need to cast it to (size_t)13?
| : |
| : | C99 type conversion rules allow this case to be promoted without a warning,
| : | because the default case of nonnegative "int" constant can be promoted to
| : | "unsigned int" and then "unsigned long" automatically.
| :
| : I know, but lint bitches.
|
| Then we should fix lint.  It shouldn't bitch on this case, because "13" is a
| nonnegative constant.

Or it should always bitch on all platforms whenever you do any implicit
conversions since they could possibly be wrong on other platforms.

| : | Not all can be made MI, mind you.  I found clock_t as one such type already,
| : | but I haven't scanned through everything.

And clock_t cannot be made MI because?

| :
| : most of them can though.
|
| Fine, so we can audit them and see which can be moved out, and move those.
|
| IMNSHO, I'd rather see these typedef'd in terms of the bitsized types where
| possible, to help readability, but that will again lead you down the path of
| incongruous types on some platforms.  Then again, some of those types can
| probably be collapsed to MI definitions too.

I disagree about fixed-sized types.  Most of these types are relative to other
types, rather than a fixed size.  That's really the issue.  A size_t or ptrdiff_t
needs to be able to handle the size of a pointer, which is a non-issue if `int'
and `long' are the same size but a very important issue if they are not.

I think it's quite obvious that size_t and ptrdiff_t would need to be int64_t
on any 64-bit platform.  But do you really want to make size_t and ptrdiff_t 
int64_t on say vax or m68k?

Eduardo