I'm trying to port some NXP demo code to Rowley Crossworks, it's
written for Keil and has a cast on the left hand side of an addition.
The Keil code has
paramstruct *p;
(uint8_t *)p++;
p is a pointer to a struct 4 bytes long. I presume this is meant to advance the
pointer 1 byte.
Crossworks won't compile this - "lvalue required as left operand of
assignment"
The best I can come up with that will compile without warnings is
p = (paramstruct *)((uint8_t *)p+1);
-which is a bit horrible - is there a good way to do this?
--
Tim Mitchell
strange casting in Keil compiler
Started by ●September 20, 2011
Reply by ●September 20, 20112011-09-20
> I'm trying to port some NXP demo code to Rowley
Crossworks, it's
> written for Keil and has a cast on the left hand side of an addition.
>
> The Keil code has
> paramstruct *p;
>
> (uint8_t *)p++;
>
> p is a pointer to a struct 4 bytes long. I presume this is meant to
> advance the pointer 1 byte.
>
> Crossworks won't compile this - "lvalue required as left operand of
> assignment"
>
> The best I can come up with that will compile without warnings is p =
> (paramstruct *)((uint8_t *)p+1);
>
> -which is a bit horrible - is there a good way to do this?
The original is a bit horrible because it's non-standard. A cast is always
an r-value, never an l-value. Code such as that should never, ever compile,
not be seen in polite company.
I fail to see why code such as this would ever be necessary. If you cast,
as you have, the meaning is 100% clear. As you are already uncertain of
what the original code does, WHY WOULD YOU SEEK TO KEEP IT?
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
> written for Keil and has a cast on the left hand side of an addition.
>
> The Keil code has
> paramstruct *p;
>
> (uint8_t *)p++;
>
> p is a pointer to a struct 4 bytes long. I presume this is meant to
> advance the pointer 1 byte.
>
> Crossworks won't compile this - "lvalue required as left operand of
> assignment"
>
> The best I can come up with that will compile without warnings is p =
> (paramstruct *)((uint8_t *)p+1);
>
> -which is a bit horrible - is there a good way to do this?
The original is a bit horrible because it's non-standard. A cast is always
an r-value, never an l-value. Code such as that should never, ever compile,
not be seen in polite company.
I fail to see why code such as this would ever be necessary. If you cast,
as you have, the meaning is 100% clear. As you are already uncertain of
what the original code does, WHY WOULD YOU SEEK TO KEEP IT?
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
Reply by ●September 20, 20112011-09-20
----Original Message----
From: l...
[mailto:l...] On Behalf Of Paul Curtis
Sent: 20 September 2011 16:23 To: l...
Subject: RE: [lpc2000] strange casting in Keil compiler
> I fail to see why code such as this would ever be
> necessary. If you cast,
> as you have, the meaning is 100% clear. As you are
> already uncertain of
> what the original code does, WHY WOULD YOU SEEK TO KEEP
> IT?
I don't want to keep it - I'm just trying to get the (usb) demo code to compile... and there's quite a lot of lvalue-casting going on in there.
As far as I can see they do this to reuse a pointer of the wrong type to point to a different type of variable.
--
Tim Mitchell
From: l...
[mailto:l...] On Behalf Of Paul Curtis
Sent: 20 September 2011 16:23 To: l...
Subject: RE: [lpc2000] strange casting in Keil compiler
> I fail to see why code such as this would ever be
> necessary. If you cast,
> as you have, the meaning is 100% clear. As you are
> already uncertain of
> what the original code does, WHY WOULD YOU SEEK TO KEEP
> IT?
I don't want to keep it - I'm just trying to get the (usb) demo code to compile... and there's quite a lot of lvalue-casting going on in there.
As far as I can see they do this to reuse a pointer of the wrong type to point to a different type of variable.
--
Tim Mitchell
Reply by ●September 20, 20112011-09-20
Hi Tim,
> ----Original Message----
> From: l...
> [mailto:l...] On Behalf Of Paul Curtis
> Sent: 20 September 2011 16:23 To: l...
> Subject: RE: [lpc2000] strange casting in Keil compiler
>
> > I fail to see why code such as this would ever be necessary. If you
> > cast, as you have, the meaning is 100% clear. As you are already
> > uncertain of what the original code does, WHY WOULD YOU SEEK TO KEEP
> > IT?
>
> I don't want to keep it - I'm just trying to get the (usb) demo code to
> compile... and there's quite a lot of lvalue-casting going on in there.
> As far as I can see they do this to reuse a pointer of the wrong type
> to point to a different type of variable.
Ok, shame on the author. Nightmare. :-( One assumes that 'volatile' may
also be a problem if this type of error is already present in the code. Oh
well.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
> ----Original Message----
> From: l...
> [mailto:l...] On Behalf Of Paul Curtis
> Sent: 20 September 2011 16:23 To: l...
> Subject: RE: [lpc2000] strange casting in Keil compiler
>
> > I fail to see why code such as this would ever be necessary. If you
> > cast, as you have, the meaning is 100% clear. As you are already
> > uncertain of what the original code does, WHY WOULD YOU SEEK TO KEEP
> > IT?
>
> I don't want to keep it - I'm just trying to get the (usb) demo code to
> compile... and there's quite a lot of lvalue-casting going on in there.
> As far as I can see they do this to reuse a pointer of the wrong type
> to point to a different type of variable.
Ok, shame on the author. Nightmare. :-( One assumes that 'volatile' may
also be a problem if this type of error is already present in the code. Oh
well.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
Reply by ●September 20, 20112011-09-20
It looks like this is ambiguous, when the cast is actually applied.
Are you trying to cast the result of the post increment operator, or cast p
as a pointer before incrementing it.
The code as it is written would perform a post increment of p, so it is
casting p with no assignment to anything
Try ((uint8_t *)p)++;
Regards
Phil.
From: l... [mailto:l...] On Behalf Of
Paul Curtis
Sent: 20 September 2011 16:23
To: l...
Subject: RE: [lpc2000] strange casting in Keil compiler
> I'm trying to port some NXP demo code to Rowley Crossworks, it's
> written for Keil and has a cast on the left hand side of an addition.
>
> The Keil code has
> paramstruct *p;
>
> (uint8_t *)p++;
>
> p is a pointer to a struct 4 bytes long. I presume this is meant to
> advance the pointer 1 byte.
>
> Crossworks won't compile this - "lvalue required as left operand of
> assignment"
>
> The best I can come up with that will compile without warnings is p > (paramstruct *)((uint8_t *)p+1);
>
> -which is a bit horrible - is there a good way to do this?
The original is a bit horrible because it's non-standard. A cast is always
an r-value, never an l-value. Code such as that should never, ever compile,
not be seen in polite company.
I fail to see why code such as this would ever be necessary. If you cast,
as you have, the meaning is 100% clear. As you are already uncertain of
what the original code does, WHY WOULD YOU SEEK TO KEEP IT?
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
Are you trying to cast the result of the post increment operator, or cast p
as a pointer before incrementing it.
The code as it is written would perform a post increment of p, so it is
casting p with no assignment to anything
Try ((uint8_t *)p)++;
Regards
Phil.
From: l... [mailto:l...] On Behalf Of
Paul Curtis
Sent: 20 September 2011 16:23
To: l...
Subject: RE: [lpc2000] strange casting in Keil compiler
> I'm trying to port some NXP demo code to Rowley Crossworks, it's
> written for Keil and has a cast on the left hand side of an addition.
>
> The Keil code has
> paramstruct *p;
>
> (uint8_t *)p++;
>
> p is a pointer to a struct 4 bytes long. I presume this is meant to
> advance the pointer 1 byte.
>
> Crossworks won't compile this - "lvalue required as left operand of
> assignment"
>
> The best I can come up with that will compile without warnings is p > (paramstruct *)((uint8_t *)p+1);
>
> -which is a bit horrible - is there a good way to do this?
The original is a bit horrible because it's non-standard. A cast is always
an r-value, never an l-value. Code such as that should never, ever compile,
not be seen in polite company.
I fail to see why code such as this would ever be necessary. If you cast,
as you have, the meaning is 100% clear. As you are already uncertain of
what the original code does, WHY WOULD YOU SEEK TO KEEP IT?
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
Reply by ●September 20, 20112011-09-20
Hi Tim,
This code makes no sense. Are you sure that it isn't
*(uint8_t *)p++ = some addition;
The line above is also a terrible code but it should compile.
--
Klaus Gromann
I'm trying to port some NXP demo code to Rowley Crossworks, it's written for Keil and has a cast on the left hand side of an addition.
The Keil code has
paramstruct *p;
(uint8_t *)p++;
p is a pointer to a struct 4 bytes long. I presume this is meant to advance the pointer 1 byte.
Crossworks won't compile this - "lvalue required as left operand of assignment"
The best I can come up with that will compile without warnings is
p = (paramstruct *)((uint8_t *)p+1);
-which is a bit horrible - is there a good way to do this?
--
Tim Mitchell
________________________________
Sample disclaimer text
This code makes no sense. Are you sure that it isn't
*(uint8_t *)p++ = some addition;
The line above is also a terrible code but it should compile.
--
Klaus Gromann
I'm trying to port some NXP demo code to Rowley Crossworks, it's written for Keil and has a cast on the left hand side of an addition.
The Keil code has
paramstruct *p;
(uint8_t *)p++;
p is a pointer to a struct 4 bytes long. I presume this is meant to advance the pointer 1 byte.
Crossworks won't compile this - "lvalue required as left operand of assignment"
The best I can come up with that will compile without warnings is
p = (paramstruct *)((uint8_t *)p+1);
-which is a bit horrible - is there a good way to do this?
--
Tim Mitchell
________________________________
Sample disclaimer text
Reply by ●September 20, 20112011-09-20
On 20/09/2011 16:35, Tim Mitchell wrote:
>
>
> ----Original Message----
> From: l...
> [mailto:l... ] On
> Behalf Of Paul Curtis
> Sent: 20 September 2011 16:23 To: l...
>
> Subject: RE: [lpc2000] strange casting in Keil compiler
>
>> I fail to see why code such as this would ever be
>> necessary. If you cast,
>> as you have, the meaning is 100% clear. As you are
>> already uncertain of
>> what the original code does, WHY WOULD YOU SEEK TO KEEP
>> IT?
>
> I don't want to keep it - I'm just trying to get the (usb) demo code to
> compile... and there's quite a lot of lvalue-casting going on in there.
> As far as I can see they do this to reuse a pointer of the wrong type to
> point to a different type of variable.
Are you sure it is not done to make it difficult to port away from their
compiler?
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.
>
>
> ----Original Message----
> From: l...
> [mailto:l... ] On
> Behalf Of Paul Curtis
> Sent: 20 September 2011 16:23 To: l...
>
> Subject: RE: [lpc2000] strange casting in Keil compiler
>
>> I fail to see why code such as this would ever be
>> necessary. If you cast,
>> as you have, the meaning is 100% clear. As you are
>> already uncertain of
>> what the original code does, WHY WOULD YOU SEEK TO KEEP
>> IT?
>
> I don't want to keep it - I'm just trying to get the (usb) demo code to
> compile... and there's quite a lot of lvalue-casting going on in there.
> As far as I can see they do this to reuse a pointer of the wrong type to
> point to a different type of variable.
Are you sure it is not done to make it difficult to port away from their
compiler?
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.
Reply by ●September 20, 20112011-09-20
Actually, this is Very dangerous code, casting a pointer to a different type
then incrementing it will corrupt the pointer, it would no longer have the
correct alignment and any further use of the pointer in its original form
could generate an unaligned load / store which will cause a hard fault.
The best thing to do if you want to access the structure contents as bytes
is make a local copy as a byte pointer.
e.g. uint8_t * pData = (uint8_t *) p;
now pData++ will work fine, p can then be discarded.
Obviously p has to be a local pointer which is discarded anyway for the
reason given above.
Regards
Phil.
From: l... [mailto:l...] On Behalf Of
Tim Mitchell
Sent: 20 September 2011 16:36
To: l...
Subject: RE: [lpc2000] strange casting in Keil compiler
----Original Message----
From: l...
[mailto:l... ] On
Behalf Of Paul Curtis
Sent: 20 September 2011 16:23 To: l...
Subject: RE: [lpc2000] strange casting in Keil compiler
> I fail to see why code such as this would ever be
> necessary. If you cast,
> as you have, the meaning is 100% clear. As you are
> already uncertain of
> what the original code does, WHY WOULD YOU SEEK TO KEEP
> IT?
I don't want to keep it - I'm just trying to get the (usb) demo code to
compile... and there's quite a lot of lvalue-casting going on in there.
As far as I can see they do this to reuse a pointer of the wrong type to
point to a different type of variable.
--
Tim Mitchell
then incrementing it will corrupt the pointer, it would no longer have the
correct alignment and any further use of the pointer in its original form
could generate an unaligned load / store which will cause a hard fault.
The best thing to do if you want to access the structure contents as bytes
is make a local copy as a byte pointer.
e.g. uint8_t * pData = (uint8_t *) p;
now pData++ will work fine, p can then be discarded.
Obviously p has to be a local pointer which is discarded anyway for the
reason given above.
Regards
Phil.
From: l... [mailto:l...] On Behalf Of
Tim Mitchell
Sent: 20 September 2011 16:36
To: l...
Subject: RE: [lpc2000] strange casting in Keil compiler
----Original Message----
From: l...
[mailto:l... ] On
Behalf Of Paul Curtis
Sent: 20 September 2011 16:23 To: l...
Subject: RE: [lpc2000] strange casting in Keil compiler
> I fail to see why code such as this would ever be
> necessary. If you cast,
> as you have, the meaning is 100% clear. As you are
> already uncertain of
> what the original code does, WHY WOULD YOU SEEK TO KEEP
> IT?
I don't want to keep it - I'm just trying to get the (usb) demo code to
compile... and there's quite a lot of lvalue-casting going on in there.
As far as I can see they do this to reuse a pointer of the wrong type to
point to a different type of variable.
--
Tim Mitchell
Reply by ●September 20, 20112011-09-20
----Original Message----
From: l...
[mailto:l...] On Behalf Of FreeRTOS Info
Sent: 20 September 2011 16:54 To: l...
Subject: Re: [lpc2000] strange casting in Keil compiler
> Are you sure it is not done to make it difficult to port
> away from their
> compiler?
It probably is. Unfortunately all NXP's demo code is written for Keil tools.
--
Tim Mitchell
From: l...
[mailto:l...] On Behalf Of FreeRTOS Info
Sent: 20 September 2011 16:54 To: l...
Subject: Re: [lpc2000] strange casting in Keil compiler
> Are you sure it is not done to make it difficult to port
> away from their
> compiler?
It probably is. Unfortunately all NXP's demo code is written for Keil tools.
--
Tim Mitchell
Reply by ●September 20, 20112011-09-20
> Are you sure it is not done to make it difficult to
port away from their
> compiler?
IAR is very good at doing this.
Have you ever tried porting IAR Demo code to say GCC etc.
Its practically impossible.
Regards
Jean-Jacques
--- In l..., FreeRTOS Info wrote:
> On 20/09/2011 16:35, Tim Mitchell wrote:
> >
> >
> > ----Original Message----
> > From: l...
> > [mailto:l... ] On
> > Behalf Of Paul Curtis
> > Sent: 20 September 2011 16:23 To: l...
> >
> > Subject: RE: [lpc2000] strange casting in Keil compiler
> >
> >> I fail to see why code such as this would ever be
> >> necessary. If you cast,
> >> as you have, the meaning is 100% clear. As you are
> >> already uncertain of
> >> what the original code does, WHY WOULD YOU SEEK TO KEEP
> >> IT?
> >
> > I don't want to keep it - I'm just trying to get the (usb) demo code to
> > compile... and there's quite a lot of lvalue-casting going on in there.
> > As far as I can see they do this to reuse a pointer of the wrong type to
> > point to a different type of variable.
>
> Are you sure it is not done to make it difficult to port away from their
> compiler?
> Regards,
> Richard.
>
> + http://www.FreeRTOS.org
> Designed for Microcontrollers.
> More than 7000 downloads per month.
>
> compiler?
IAR is very good at doing this.
Have you ever tried porting IAR Demo code to say GCC etc.
Its practically impossible.
Regards
Jean-Jacques
--- In l..., FreeRTOS Info wrote:
> On 20/09/2011 16:35, Tim Mitchell wrote:
> >
> >
> > ----Original Message----
> > From: l...
> > [mailto:l... ] On
> > Behalf Of Paul Curtis
> > Sent: 20 September 2011 16:23 To: l...
> >
> > Subject: RE: [lpc2000] strange casting in Keil compiler
> >
> >> I fail to see why code such as this would ever be
> >> necessary. If you cast,
> >> as you have, the meaning is 100% clear. As you are
> >> already uncertain of
> >> what the original code does, WHY WOULD YOU SEEK TO KEEP
> >> IT?
> >
> > I don't want to keep it - I'm just trying to get the (usb) demo code to
> > compile... and there's quite a lot of lvalue-casting going on in there.
> > As far as I can see they do this to reuse a pointer of the wrong type to
> > point to a different type of variable.
>
> Are you sure it is not done to make it difficult to port away from their
> compiler?
> Regards,
> Richard.
>
> + http://www.FreeRTOS.org
> Designed for Microcontrollers.
> More than 7000 downloads per month.
>