Re: pointer <-> integer round-up

[Joe Buck <Joe dot Buck at synopsys dot com>]

> ><       For any warning given for legal constructs, there must be
> >       either a (strongly) portable code change that can eliminate
> >       the warning without alterning the meaning of the program,
> >       or an option which disables that warning (but no others).

At 11:04 PM -0500 3/20/02, Robert Dewar wrote:
> >YOu can state such a rule, but you have not provided a convincing argument
> >that it is a desirable rule in my opinion.

Alan Lehotsky writes:
> How about the fact that *many* organizations have development processes
> that require that the product builds must compile without any warnings
> or errors?

I would agree with Alan if the rule were stated in a somewhat weaker way:
if there is a warning that is included in -Wall, for any program that
produces a warning, it should be possible to modify the program to
eliminate the warning without making the program significantly worse in
performance or size.  An example of a warning that doesn't meet that
criterion are the "effective C++" warnings that insist that some classes
have a virtual destructor when this is unnecessary, which adds unnecessary
time and space overhead to programs.

Also, there are differences between language-lawyer portability and
practical portability.

In the case of C/C++, a given program may make assumptions beyond the
scope of the standard because the given properties are true for all
target platforms of interest.  Typical assumptions I've often seen is
that the target machine fits into one of a limited number of categories,
e.g. ILP32 (ints, longs, and pointers are 32 bits) or LP64 (longs and
pointers are 64 bits).  If these are the only two categories of interest,
it is safe for the programmer to assume that "long" and "pointer" are the
same size, even though ISO C doesn't make such a promise.  If this
programmer can't get the compiler to shut up, he or she will be extremely
annoyed at the compiler provider.  And code that does a cast that may
lose value may, in fact, be inside an #ifdef that assures that the
cast is completely valid.

In an ideal world, the user would be able to explicitly inform the
compiler about what assumptions of this type that s/he is making.
(In cases like the above, assertions might do the job).