Michael Press
2/10/2011 2:24:00 AM
In article <kfn62t951jq.fsf@x-alumni2.alumni.caltech.edu>,
Tim Rentsch <txr@alumni.caltech.edu> wrote:
> Michael Press <rubrum@pacbell.net> writes:
>
> > In article <kfnsjx41k4q.fsf@x-alumni2.alumni.caltech.edu>,
> > Tim Rentsch <txr@alumni.caltech.edu> wrote:
> >
> >> Ian Collins <ian-news@hotmail.com> writes:
> >
> > [...]
> >
> >> > That wasn't how I read it.
> >>
> >> It would help if you could be a little more explicit in
> >> saying just what interpretation you believe is actually
> >> the case. I will start the ball rolling. The program
> >> copx posted:
> >>
> >> #include <stdio.h>
> >>
> >> void foo(const int *c)
> >> {
> >> *((int *)c) = 'B';
> >> }
> >>
> >>
> >> int main(void)
> >> {
> >> int a = 'A';
> >> foo(&a);
> >> putchar(a);
> >> return 0;
> >> }
> >>
> >> does _not_ have any undefined behavior. Do you dispute
> >> that? If so, please cite those sections of the Standard
> >> that support your view.
> >
> > That code is in some kind of difficulty.
> > Suppose foo's caller wants and expects the value retained (*&a)?
> >
> > $ cc -Wcast-qual try.c
> > try.c: In function 'foo':
> > try.c:5: warning: cast discards qualifiers from pointer target type
> >
> > $ cat -n try.c
> > 1 #include <stdio.h>
> > 2
> > 3 void foo(const int *c)
> > 4 {
> > 5 *((int *)c) = 'B';
> > 6 }
> > 7
> > 8
> > 9 int main(void)
> > 10 {
> > 11 int a = 'A';
> > 12 foo(&a);
> > 13 putchar(a);
> > 14 return 0;
> > 15 }
>
> It seems you are confusing several different kinds of
> circumstances, more specifically,
>
> 1. undefined behavior
> 2. constraint violations
> 3. warning messages
> 4. style-violation advisories
>
> The presence of a warning message or a style-violation advisory
> message does not necessarily imply either a constraint violation or
> undefined behavior. Despite the gcc-produced warning message (and
> whatever style rules one might think are violated) the code above
> _must change_ the value of the variable 'a' as part of the function
> call 'foo(&a)'; any other result means the implementation is not
> conforming.
>
> Stylistically I might agree that the code above is bad, but
> my earlier comment was only about whether it is well-defined
> (which it is, not counting the missing final newline on output).
> If someone wants to change the topic to discuss whether this
> code is bad style, may I suggest starting a new thread for
> that topic?
I dare not start a thread on style.
Thank you for explaining the technicalities,
and helping me think this through.
--
Michael Press