Michael Press
2/10/2011 2:19:00 AM
In article <ihmfdn$mne$1@news.eternal-september.org>,
James Kuyper <jameskuyper@verizon.net> wrote:
> On 01/24/2011 03:36 PM, Michael Press wrote:
> > In article<ihibat$k9l$1@news.eternal-september.org>,
> > James Kuyper<jameskuyper@verizon.net> wrote:
> >
> >> On 01/23/2011 05:02 PM, Michael Press wrote:
> >>> In article<ihh6va$pun$1@news.eternal-september.org>,
> >>> James Kuyper<jameskuyper@verizon.net> wrote:
> ...
> >>>> The fact that a warning
> >>>> was issued is not relevant to the question of whether or not this code
> >>>> has defined behavior.
> >>>
> >>> It is a question---a question that two people evaded.
> >>> Why have the warning at all?
> >>
> >> Because it's risky code.
> >
> > Yes, I implied that is my view all along.
>
> That may have been your intent, but you seemed to be weighing in on the
> side of those who describe such code as a "lie".
Thank you for replying at length to my questions.
They are questions; even though I express myself
categorically to make myself plain. I am not taking
sides, and not calling anyone a liar---do not know
enough to do so.
> I believe that, in the
> context of standard C, the only assumptions that an implementation is
> allowed to make about the intended meaning of a programmer's code are
> those assumptions which could only be violated by code with undefined
> behavior. In other words, I don't consider it a lie to the compiler
> unless it renders the behavior of the code undefined, which is a much
> stronger statement than merely saying that the code is risky.
>
> > I need to reiterate something I said earlier. When I
> > call foo(const int *) I expect the compiler to tag
> > the writer of foo for abrogating his agreement with me.
>
> If you have an agreement with him that goes beyond the writing of code
> with no syntax errors, no constraint violations, and no undefined
> behavior, the details of that agreement are a matter for negotiation.
> The compiler cannot reasonably be expected to know the terms of that
> agreement. it's only responsible for diagnosing syntax errors and
> constraint violations; this is neither.
>
> > The following code gets an _error_
> > int main(void)
> > {
> > const int n = 10;
> > n = 9;
> > return 0;
> > }
> >
> > but casting away const only gets a warning if the
> > code writer goes out of his way to turn on the warning.
>
> As a general rule, safe conversions can be made to occur automatically,
> without a cast; conversions that must be specifically requested by use
> of a cast-expression are the dangerous ones. The use of a cast should
> always be taken as a sign the code it occurs in should be reviewed with
> more than the usual amount of caution. When you use a cast expression,
> you are, in effect, telling the compiler "I know what I'm doing, don't
> bother me about this."
>
> Using -cast-qual essentially says "I was lying when I said I know what
> I'm doing - please remind me of the cases where you think I might have
> been mistaken". If you're sloppy about your use of casts, that can be an
> important piece of information to give to the compiler.
Again, thank you.
--
Michael Press