Dave,
Sorry to be blunt, but you are incorrect when you state the left and
right are not the same types. This might explain why you think the
compiler is in error.
> int *ip;
>
> ip = (int *)&buf[i];
>
1. LHS: "ip" is declared as "int *"
2. RHS: regardless of what &buf[i] is declared as, you have forced
the compiler to treat it as "int *" : that's what an explicit type
cast does.
In other words, the RHS is exactly the same as the LHS. Hence no
warning.
I sympathise with your dilema in how to move from an existing (non-
portable) code base.
My suggestion would be to re-code the offending constructs: you're
going to have to go through your code line-by-line in any case. You
may as well fix it as you go. My strong recommendation would be not
to use "packed" or any other such modifier: it's inherently non-
portable. You might get it to work for now, but what happens when
you next move compiler or target?
The safest (i.e. portable) and simplest way of pulling bytes out of
a buffer of bytes like this is to do it a byte at a time. As someone
else has pointed out, this issue is very common in comms protocol
software. Unfortunately there exist many, many examples of code that
are inherently non-portable, which people have a habit of following.
Brendan
--- In lpc2000@yahoogroups.com, "dsidlauskas1" <dsidlauskas@...>
wrote:
>
> Jaya,
>
> The "vanilla" cast is only to be treated as a byte packed cast if
the
> object that is being cast is itself byte packed.
>
> In thinking about my original case, the compiler should at least
warn
> since, with;
>
> char buf[]={...};
> int *ip;
>
> ip = (int *)&buf[i];
>
> the left and right side of this assignment are not of the same
type,
> even though the declaration would have you think so. ip is a
pointer
> to a default word aligned object, and (int *)&buf[i] is a pointer
to a
> byte aligned object. These are really not the same data types.
>
> But I'm afraid I may be getting ahead of myself here. If I'm not
> careful someone is going to smack me with the C99 spec :-).
>
> I'll stick with my original assertion that the compiler could deal
> with this issue in a more useful way than it does.
>
> Dave S.
>
>
>
>
> --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@> wrote:
> >
> > Dave,
> >
> > If I understand you (now more correctly): because byte packing is
> > default, you want a vanilla cast (without __packed prefix) to be
> > treated as byte packed cast.
> >
> > How would a programmer then indicate a cast to a vanilla (not
packed)
> > pointer?
> >
> > If the compiler always assumes byte packed no matter what,
arguably
> > the compiler cannot take advantage of the faster method of
dealing
> > with composite objects.
> >
> > Jaya
> >
> > --- In lpc2000@yahoogroups.com, "dsidlauskas1" <dsidlauskas@>
wrote:
> > >
> > > Jaya,
> > >
> > > I don't think I'm asking it to connect the two statements.
> > >
> > > What I'm expecting it to do is to recognize that buf is a byte
packed
> > > object (the defalt for the compler)and when casting byte packed
> > > objects the compiler should cast them to other byte packed
objects.
> > >
> > > in otherwords;
> > >
> > > char buf[10];
> > > int ip*;
> > >
> > > ip = (int *)&buf[5];
> > >
> > > should be treated by the compiler as:
> > >
> > > ip = (__packed int *)&buf[5];
> > >
> > > and this is because char buf[10] is a byte packed object for
this
> > > compiler.
> > >
> > > Dave
> >
>Message
Re: For C Experts
2006-03-31 by brendanmurphy37
Attachments
- No local attachments were found for this message.