Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: For C Experts

2006-03-31 by brendanmurphy37

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
> >
>

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.