Re: [avr-gcc-list] Deprecated warning on 3.4.1

[David Brown]

> At 09:05 05.08.2004 +0200, David Brown wrote:
> >Such casts should certainly issue a warning, as they could easily lead to
> >problems, at least on other processors.  Suppose you are using a
processor
> >which requires 16-bit data to be aligned properly, and src is a pointer
to
> >such data (unsigned short*).  Then the ((unsigned char *) src)++
expresion
> >leaves "src" with a value that is illegal for its type - not a good thing
to
> >do.  In general, the effect to arithmetic (like ++) on a variable is
> >dependand on its exact type, so messing with that type is a bad plan.
>
> I fully understand this, but...
>
>
>
> >I would say that a better way to write such code would be to introduce a
new
> >local variable of type (unsigned char*), initialised to src.  You can
then
> >use the new pointer freely.
>
> In some cases this may introduce additional code, which
> can break the application. Remember, we are not talking about
> PCs, but embedded systems, where portability is not always
> the main focus. Instead developers often count the number of
> machine cycles. Thus, it's not "OK, let's use another local
> variable for free." In my case it is bootloader code, where
> every byte counts and portability is absolutely no issue.
>

Portability is a focus of gcc - it's not an embedded system compiler.
Sometimes that means that changes that are "free" on big systems will cost
on the small systems - it's the price we pay for getting things like the
front-end optomisations for free.

Having said that, the idea of wasting code space, data space, or time
unnecessarily would bug me too.  However, I would estimate that using such
an extra variable would be optomised away by the compiler, and may well
produce better code (for example, if the original "src" was a global
variable).  Unless you are compiling without optomisation, introducing new
local variables does not necessarily mean extra code, data or time.

> Nevertheless I understood now, that this compiler warning
> makes sense.
>
> Thanks,
>
> Harald
>
>
>
> _______________________________________________
> avr-gcc-list mailing list
> address@hidden
> http://www.avr1.org/mailman/listinfo/avr-gcc-list
>