On Sat, 15 Sep 2018, Neil wrote:

> Hi all,
>
> I've got bitmaps defined using const (to store it in program memory) in
> my PIC32 code as...
> const unsigned char Logo1Bitmap[312] =3D
> {
>     0x00, 0x00, 0x1F, 0xFF, 0xFF, 0xFF, 0xF0,
>     0x00, 0x07, 0xFF, 0xFF, 0xFF, 0xFF, 0xF0,
>     ...
> }
>
>
> I also have this function...
> void DrawBitmap(signed short XPos, signed short YPos, signed short
> width, signed short height, unsigned char *bitmap, unsigned short color);
>
>
> When I pass the bitmap to the function like this...
>       DrawBitmap(85, 28, 52, 42, Logo1Bitmap, 0x7BEF);
>
>
> I get warning messages like this...
> warning: passing argument 5 of 'DrawBitmap' discards 'const' qualifier
> from pointer target type [enabled by default]
>        DrawBitmap(85, 28, 52, 42, Logo1Bitmap, 0x7BEF);
>
> The only way I can get the warning to go away is to do this...
>        DrawBitmap(85, 28, 52, 42, (unsigned char *)&Logo1Bitmap[0],
> 0x7BEF);
>
>
> It works properly either way, but I'm unclear what it thinks I'm doing
> wrong.  And what's the right way to do this?

Think of it like this: the function has an inside and an outside. The=20
interface to the function (the formal arguments) tell the compiler how the=
=20
function will interact with the outside. The compiler does not actually=20
check the inside of the function when a function is called, it just takes=20
it for granted the interface adequatly describes the inside.

The compiler compiles the inside of the function seperatly from the=20
outside and relies on both sides obeying the definition of the interface.

On the inside, the function might actually use the stuff passed to it in=20
an unexpected manor, not consitant with the interface at all.

if you have a function
 	DrawBitmap(int x1, int y1, int x2, int y2, char *bitmap)

This actually tells the compiler DrawBitmap could modify the contents of
bitmap. It doesn't mater that DrawBitmap does not actually change the=20
contents of bitmap.

if you redefine the function as
 	DrawBitmap(int x1, int y1, int x2, int y2, const char *bitmap)

This tells the compiler that DrawBitmap WILL NOT modify the contents of=20
bitmap. When the compiler compiles the inside of the function it will=20
complain if it attempts to modify the contents of bitmap.

Be very VERY wary of casting to get you out of trouble. Some architecture
treat pointers to RAM as distinct from pointers to code space. This means=20
that although the casting might work perfectly well on one platform it
might fall over if you try to port your code to a different architecture=20
(e.g. PIC16 or a CPU with 16 bit ints instead of 32 bit) and leave you=20
with a hard to find bug.

One last word of warning about casting: it is evil, don't do it!!! No=20
seriously it's a beartrap waiting to bite you.

It basically says to the compiler, I don't care what you think, do this=20
anyway.

Consider the following

int fred(char *ptr)
{
 	*(float *)ptr =3D 3.1415;
}

#defne	max_buff_len 32

char	jack[max_buff_len];

 	fred(&jack);

Now imagine that "max_buff_len", "jack" and "fred" are defined somewhere=20
spread across several files and a few thousand lines of source code. What=20
happens when you change something that involves these 3 items. The=20
compiler wont flag an error if it spots as inconsistancy. You told it not=20
to by virtue of the cast.

Moral is: casts =3D bad.

Regards
Sergio Masci
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.