This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Network programming for eCos under linux
- To: "'Jonathan Larmour'" <jlarmour at redhat dot com>,"'Grant Edwards'" <grante at visi dot com>
- Subject: RE: [ECOS] Network programming for eCos under linux
- From: "Trenton D. Adams" <tadams at theone dot dnsalias dot com>
- Date: Wed, 8 Aug 2001 09:06:06 -0600
- Cc: "'Andrew Lunn'" <andrew dot lunn at ascom dot ch>,"'eCos discussion'" <ecos-discuss at sources dot redhat dot com>
> >
> > AFAICT, that should work on an ARM. If it doesn't, it is a
> > compiler bug.
>
> Agreed. It would be different if you were accessing a more strictly
> aligned
> type through a less strictly aligned type, e.g. casting a char * to
a
> short
> * and dereferencing; as Grant says...
>
So, you're not supposed to use a "char buffer[1024];" for a generic
buffer then? If not, how should one create a generic buffer?
So, the following gcc parameter would only warn when there is a problem
with that particular architecture that you're compiling for?
-Wcast-align
The one below would make it an error to cast from a char * to an int *?
-mstrict-align
So, how would one go about making a buffer word aligned or DWORD aligned
just to be safe?
> > > Maybe i don't have the casts correct.
> >
> > There are other casts that are not going to work on ARM
> > architecture (accessing words on non-word boundaries, for
> > example). That's not a compiler error, it's just another way
> > to shoot yourself in the foot with C.
>
> Although it's worth mentioning that not all architectures disallow
> unaligned accesses which is why people think they can get away with
it
> :).
>
This goes back to the -Wcast-align. If -Wall is on, that means all
warnings right?