🚀 go-pugleaf

Morgan Herrington wrote:
> 
> Daniel Wood <dwood> writes:
> 
> > The following:
> >       ((char *)src)++;        /* src is an (int *) */
> > when compiled using Solaris SparcWorks 3.0.1, generates:
> >       "t.c", line 12: warning: a cast does not yield an lvalue
> >
> > I fully understand why it makes no sense to say:
> >
> >       (char *)src = x;
> >
> > but, if the compiler thinks that it is stupid to interpret:
> >
> >       ((char *)src)++;
> > as:
> >       (char *)src = (char *)src + 1;
> >
> > then why is it doing it, since I am intending:
> >
> >       src = (char *)src + 1;
> 
> Or to avoid a pointer mismatch warning:
> 
>         src = (int*)((char *)src + 1);
> 
> > A cast on an operator like "++" should only be applied to the RHS.
> >
> > What does the standard say?
> 
> "The operand of the postfix increment or decrement operator shall
> have qualified or unqualified scalar type and shall be a modifiable 
> lvalue."
[snip]

I think you should also add that a cast does not produce an lvalue, 
which therefore (together with the above quote) makes

  ((char *)src)++;

illegal (where src in an int *). Apart from the standard saying so,
there is a good reason why the above (and the variants using casts)
shouldn't be used. Take an implementation where char * and int *
have a different size, say an int * has two bits less than a char *
(this machine has 32 bit ints, 8 bit chars, and requires accesses to
be aligned). In this implementation what is the above supposed to
do? If it creates a temporary char *, increments that, and then
converts it back you'll end up with the same pointer. This is all
implementation defined of course, but this would be a conforming
implementation.

The upshot is, why are you doing this? Do you want to step through
and int (or array of ints) using a char *? If so, create one yourself
and use that to step through, e.g.

  char *tmp_ptr = (char *) src;
  ...
  tmp_ptr++;

This is legal on any machine (though the values you get when
dereferencing the tmp_ptr will be implementation defined, due to
things like byte order).


  Cheers,

  Ronald