Hi Everyone,

I got a help info from old message of A. Den Toom's reply.

http://en.mikrocontroller.net/topic/64486#73570

if I define struct as: _attribute_ ((_packed_))


typedef struct _attribute_ ((_packed_))
{
  char      psPartCode[512-64-2];    //!< pad so struct is 512b
  unsigned char  psPart[64];          //!< four partition records (64 
bytes)
  unsigned char  psBootSectSig0;      //!< two signature bytes (2 bytes)
  unsigned char  psBootSectSig1;
  #define     BOOTSIG0        0x55
  #define     BOOTSIG1        0xaa
}partsector;

The awrning is gone. Thanks

Min Ge

Hi everyone,

I got this warning again, but not on structure.
Just when I convet an array (char array) address to long int pointer

fat32Buffer= (unsigned long *)FatCache;

FatCache is array of

char FatCache [512];

I do not know how to get rid of the warning on such code.

thanks.

Min ge

Try:

char FatCache[512]  _attribute_ ((aligned)) ;


Ref:
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Variable-Attributes.html#Variable-Attributes

Clifford

Clifford Slocombe wrote:
> Try:
>
> char FatCache[512]  _attribute_ ((aligned)) ;
>
>
> Ref:
> 
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Variable-Attributes.html#Variable-Attributes
>
> Clifford

Hi Clifford,

Thanks for you help. I did have tried what you wrote with

char FatCache[512]  _attribute_ ((aligned (4))) ;

I am pretty sure the array start with multiples of 4. I just do not want
the warning infomation display anymore.

I know if I get rid of "-Wcast-align" in makefile, this warning will be
gone.
But I do not want, I still hope the warning to display if I have such
problem.

Thanks.

Min Ge

Min Ge wrote:

> Thanks for you help. I did have tried what you wrote with
>
> char FatCache[512]  _attribute_ ((aligned (4))) ;
>
> I am pretty sure the array start with multiples of 4. I just do not want
> the warning infomation display anymore.

You are not clear whether that solved the problem or not, or whether you
tried exactly what I suggested. Without the parameter, the alignment
will be set to the 'maximum useful alignment for the target machine', so
you need make no assumptions.

However, I don't think this is a solution: The documentation for
-Wcast-align simply states it will generate a warning when such a cast
is made. It does not say that the warning will only be issued when the
alignment is increased.

Min Ge wrote:
> I know if I get rid of "-Wcast-align" in makefile, this warning will be
> gone.
> But I do not want, I still hope the warning to display if I have such
> problem.

Note that the warning is not that the cast is misalighed, merely that
alignment is increased to make the cast safe - so the issuing of the
warning is entirely unnecessary. It is only potentially relevant if you
are down to your last few bytes of RAM, when the potential realignment
may waste as much as three bytes! You will probably find however that
the compiler is smart enough to align the data on word boundaries in any
case since this results in potentially faster code.

There are generally few reasons to switch on any warnings other than
-Wall (and possibly -Wformat). If you have a genuine reason for having
this warning, then you need to rewrite your code to avoid it. Casts are
often indicitive of a general failure in design in anycase, and you
should consider your coding practices.

A simple way to avoid the issue is to ensure type agreement in the first
instance so casts are unnecessary. A simple solution to your problem is
to declare the array thus:


FatCache is array of

unsigned long FatCache [128];
fat32Buffer = FatCache;

If you later need to access FatCache as a char array, casting to char*
will not cause the warning because the alignment need not be increased.
An possibly better alternative is to switch the declarations:

unsigned long fat32Buffer[128];
FatCache = (char*)fat32Buffer ;

Clifford

Clifford Slocombe wrote:

> unsigned long FatCache [128];
> fat32Buffer = FatCache;
>
> If you later need to access FatCache as a char array, casting to char*
> will not cause the warning because the alignment need not be increased.
> An possibly better alternative is to switch the declarations:
>
> unsigned long fat32Buffer[128];
> FatCache = (char*)fat32Buffer ;
>
> Clifford

This is a good idea. I will try it.
Thanks a lot.

Min Ge