[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Brown
Subject: Re: [avr-gcc-list] Deprecated warning on 3.4.1
Date: Thu, 5 Aug 2004 13:04:25 +0200

> 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
> >which requires 16-bit data to be aligned properly, and src is a pointer
> >such data (unsigned short*).  Then the ((unsigned char *) src)++
> >leaves "src" with a value that is illegal for its type - not a good thing
> >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
> >local variable of type (unsigned char*), initialised to src.  You can
> >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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]