> I'm sorry I got a bit snotty. I really shouldn't get annoyed
> when people post bogus answers. For whatever reason it seems
> to happen pretty frequently in this mailing list and I jumped
> the gun a bit.

That's OK Grant, I'm glad we've got that cleared up.
Perhaps I could have been more clearer in my post, dunno, I'll try to keep this in mind -
no worries.

Best Regards,
Kris

________________________________________
From: m... [mailto:m...] On Behalf Of Grant Edwards
Sent: Friday, 4 May 2007 1:31 PM
To: m...
Subject: [msp430] Re: expression has not efect

On 2007-05-04, Microbit wrote:

> Eg. toupper() could be implemented as a macro or as a func
> call, or both. I've come across such issue where the macro
> version had a bug in it, so I had to enclose the toupper in
> parentheses to force the compiler to make a function call to
> the lib - rather than to use the macro definition for it.

OK, now I see what you mean. From the context in which your
post appeared, I read it as claiming that parens around the
lvalue in an assignment statement would force a function call
to be made.

> I don't know if you're trying to be helpful or just being
> contrary - in any case, that was why I made the comment.

I'm sorry I got a bit snotty. I really shouldn't get annoyed
when people post bogus answers. For whatever reason it seems
to happen pretty frequently in this mailing list and I jumped
the gun a bit.

--
Grant Edwards grante Yow! -- In 1962, you could
at buy a pair of SHARKSKIN
visi.com SLACKS, with a "Continental
Belt," for $10.99!!

Beginning Microcontrollers with the MSP430

On 2007-05-04, Microbit wrote:

> Eg. toupper() could be implemented as a macro or as a func
> call, or both. I've come across such issue where the macro
> version had a bug in it, so I had to enclose the toupper in
> parentheses to force the compiler to make a function call to
> the lib - rather than to use the macro definition for it.

OK, now I see what you mean. From the context in which your
post appeared, I read it as claiming that parens around the
lvalue in an assignment statement would force a function call
to be made.

> I don't know if you're trying to be helpful or just being
> contrary - in any case, that was why I made the comment.

I'm sorry I got a bit snotty. I really shouldn't get annoyed
when people post bogus answers. For whatever reason it seems
to happen pretty frequently in this mailing list and I jumped
the gun a bit.

--
Grant Edwards grante Yow! -- In 1962, you could
at buy a pair of SHARKSKIN
visi.com SLACKS, with a "Continental
Belt," for $10.99!!

[People, if you don't know C, please regrain from just making
stuff up in response to questions about C. If you don't know
the answer, just don't answer.]
>>>>

Grant,

Given your knowledge of C I think you know all too well what I'm referring to.

I'm talking about that the OP (of parenthesis issue) perhaps referred to func call vs macro
on eg. ANSI lib stuff in mistake ?

Eg. toupper() could be implemented as a macro or as a func call, or both.
I've come across such issue where the macro version had a bug in it, so I had to enclose the
toupper in parentheses to force the compiler to make a function call to the lib - rather than to
use the macro definition for it.

I dont know if you're trying to be helpful or just being contrary - in any case, that was why I
made the comment.

Best Regards,
Kris

________________________________________
From: m... [mailto:m...] On Behalf Of Grant Edwards
Sent: Friday, 4 May 2007 12:37 AM
To: m...
Subject: [msp430] Re: expression has not efect

On 2007-05-03, Microbit wrote:

>> The problem is in the macro definition. You need to remove the
>> parenthesis from the 'a' variable. Since it is in parenthesis,
>> it gets turned into a value, not a variable.
>
> I think you mean that the parenthesis forces the compiler to
> use a function call and is not allowed to use a macro def - if
> it exists.

The parens around the lvalues in the macros below do not force
any sort of function call.

#define bit_clear(a,b) ((a) &= ~(1 << (b)))
#define bit_set(a,b) ((a) |= (1 << (b)))

Saying that then paren's around the lvalue force a function
call is as nonsensical as claiming that they are "turning a
variable into a value".

> Of course this is where func calls actually exist...

I haven't a clue what that means.

[People, if you don't know C, please regrain from just making
stuff up in response to questions about C. If you don't know
the answer, just don't answer.]

--
Grant Edwards grante Yow! Gibble, Gobble, we
at ACCEPT YOU ...
visi.com

On 2007-05-03, Microbit wrote:

>> The problem is in the macro definition. You need to remove the
>> parenthesis from the 'a' variable. Since it is in parenthesis,
>> it gets turned into a value, not a variable.
>
> I think you mean that the parenthesis forces the compiler to
> use a function call and is not allowed to use a macro def - if
> it exists.

The parens around the lvalues in the macros below do not force
any sort of function call.

#define bit_clear(a,b) ((a) &= ~(1 << (b)))
#define bit_set(a,b) ((a) |= (1 << (b)))

Saying that then paren's around the lvalue force a function
call is as nonsensical as claiming that they are "turning a
variable into a value".

> Of course this is where func calls actually exist...

I haven't a clue what that means.

[People, if you don't know C, please regrain from just making
stuff up in response to questions about C. If you don't know
the answer, just don't answer.]

--
Grant Edwards grante Yow! Gibble, Gobble, we
at ACCEPT YOU ...
visi.com

I got recently bounced for some exotic reason, so this is also a test reply.

> The problem is in the macro definition. You need to remove the
> parenthesis from the 'a' variable. Since it is in parenthesis,
> it gets turned into a value, not a variable.

I think you mean that the parenthesis forces the compiler to use a function call and is not
allowed to use a macro def - if it exists.
Of course this is where func calls actually exist...

Best Regards,
Kris

________________________________________
From: m... [mailto:m...] On Behalf Of Grant Edwards
Sent: Thursday, 3 May 2007 10:40 AM
To: m...
Subject: [msp430] Re: expression has not efect

On 2007-04-30, rascal_robot wrote:

> The problem is in the macro definition. You need to remove the
> parenthesis from the 'a' variable. Since it is in parenthesis,
> it gets turned into a value, not a variable.

Where does the C spec say that?

> For instance ...
>
> int x = 0;
>
> (x) |= 9; // this doesn't assign anything to x

What?

Every C compiler I've ever used would assign a value to x. I
believe that not doing so would be a violation of the language
spec.

> Change your macro to ...
>
> #define bit_set(a,b) a |= (1 << (b))
>
> See if that makes any difference.

How about you tell us what compiler you're using that doesn't
do an assignment operation when the lvalue has parens around
it.

--
Grant Edwards grante Yow! Should I get
at locked in the PRINCICAL'S
visi.com OFFICE today -- or have
a VASECTOMY??

On 2007-04-30, rascal_robot wrote:

> The problem is in the macro definition. You need to remove the
> parenthesis from the 'a' variable. Since it is in parenthesis,
> it gets turned into a value, not a variable.

Where does the C spec say that?

> For instance ...
>
> int x = 0;
>
> (x) |= 9; // this doesn't assign anything to x

What?

Every C compiler I've ever used would assign a value to x. I
believe that not doing so would be a violation of the language
spec.

> Change your macro to ...
>
> #define bit_set(a,b) a |= (1 << (b))
>
> See if that makes any difference.

How about you tell us what compiler you're using that doesn't
do an assignment operation when the lvalue has parens around
it.

--
Grant Edwards grante Yow! Should I get
at locked in the PRINCICAL'S
visi.com OFFICE today -- or have
a VASECTOMY??

The problem is in the macro definition.
You need to remove the parenthesis from the 'a' variable.
Since it is in parenthesis, it gets turned into a value, not a variable.

For instance ...

int x = 0;

(x) |= 9; // this doesn't assign anything to x

Change your macro to ...

#define bit_set(a,b) a |= (1 << (b))

See if that makes any difference.

--- In m..., "Daniel H. Sagarra"
wrote:
>
> You are right .
> sorry I shold use this define
>
> #define bit_clear(a,b) ((a) &= ~(1 << (b)))
> #define bit_set(a,b) ((a) |= (1 << (b)))
> Best regards
> Daniel H. Sagarra
> Buenos Airesm Argentina

You are right .
sorry I shold use this define

#define bit_clear(a,b) ((a) &= ~(1 << (b)))
#define bit_set(a,b) ((a) |= (1 << (b)))
Best regards
Daniel H. Sagarra
Buenos Airesm Argentina

----- Original Message -----
From: Rachel Adamec
To: m...
Sent: Sunday, April 29, 2007 8:15 AM
Subject: RE: [msp430] expression has not efect
HI Daniel,

I may be getting tripped up by what you wrote, but I think you're saying
that, with this code, the error persists... even if you change the line to
"i=bit_set(i,3);" If I'm not clear or not understanding what you're saying,
I'm sorry.

What you included was:

> main()
> {
> static int i = 1;
> bit_set (i,3); // this statment trigger a warring: expression has no efect
> i |= (1<<3); // this not trigger anything
> i++;
> while(1);
> }

Again, the result of your bit_set operation is not used, not assigned to a
variable, not saved. I wonder if you think your statement is supposed to set
the "b" bit of the "a" variable. If so, you have an error in your "define"

> #define bit_set(a,b) ((a) | (1 << (b)))

Maybe you want it to read:

#define bit_set(a,b) ((a) |= (1 << (b)))

(note the '=' included in the define)?

Or your code could read:

i = bit_set (i,3);

Hope this helps.

Rachel Adamec
Norristown, PA, USA
-----Original Message-----
From: m... [mailto:m...] On Behalf Of
Daniel H. Sagarra
Subject: Re: [msp430] expression has not efect

Dear Reachel

I wrote a short source code to despite the problem,
even doing something else with the var i, after i = bit_set(3,i),
the warring persist,, I post the code with "a equivalent statment"
without using the macro, this statment dont trigger any warring,
all optimizacion are off (best debugging code),
for some else who don't read my first code, here is it again:

#define bit_set(a,b) ((a) | (1 << (b)))

main()
{
static int i = 1;
bit_set (i,3); // this statment trigger a warring: expression has no efect
i |= (1<<3); // this not trigger anything
i++;
while(1);
}

.

0851/stime77790369/nc1E07179/nc2848641/nc3=3>

------
E-mail clasificado por el Idenfificador de Spam Inteligente. Para modificar la categor clasificada acceda a su webmail
------
Este mensaje ha sido verificado por el E-mail Protegido. Antivirus Actualizado en 27/04/2007 / Versi: 5.1.00/5019

HI Daniel,

I may be getting tripped up by what you wrote, but I think you're saying
that, with this code, the error persists... even if you change the line to
"i=bit_set(i,3);" If I'm not clear or not understanding what you're saying,
I'm sorry.

What you included was:

> main()
> {
> static int i = 1;
> bit_set (i,3); // this statment trigger a warring: expression has no efect
> i |= (1<<3); // this not trigger anything
> i++;
> while(1);
> }

Again, the result of your bit_set operation is not used, not assigned to a
variable, not saved. I wonder if you think your statement is supposed to set
the "b" bit of the "a" variable. If so, you have an error in your "define"

> #define bit_set(a,b) ((a) | (1 << (b)))

Maybe you want it to read:

#define bit_set(a,b) ((a) |= (1 << (b)))

(note the '=' included in the define)?

Or your code could read:

i = bit_set (i,3);

Hope this helps.

Rachel Adamec
Norristown, PA, USA

-----Original Message-----
From: m... [mailto:m...] On Behalf Of
Daniel H. Sagarra
Subject: Re: [msp430] expression has not efect

Dear Reachel

I wrote a short source code to despite the problem,
even doing something else with the var i, after i = bit_set(3,i),
the warring persist,, I post the code with "a equivalent statment"
without using the macro, this statment dont trigger any warring,
all optimizacion are off (best debugging code),
for some else who don't read my first code, here is it again:

#define bit_set(a,b) ((a) | (1 << (b)))

main()
{
static int i = 1;
bit_set (i,3); // this statment trigger a warring: expression has no efect
i |= (1<<3); // this not trigger anything
i++;
while(1);
}

.

0851/stime77790369/nc1E07179/nc2848641/nc3=3>

Have you tried saying that i = set_bit(a, b)?

To me, it having "No effect" means that the expression is evaluated,
however, nothing is done with the result.

On 4/28/07, Daniel H. Sagarra wrote:
>
> Warning[Pe174]: expression has no effect
> C:\Proyectos\IAR\msp430\bit_lib\bit_lib.c 8
> .lst:
>
> C:\Proyectos\IAR\msp430\bit_lib\bit_lib.c
> 1 #include
> 2
> 3 #define bit_set(a,b) ((a) | (1 << (b)))
> 4
>
> \ In segment CODE, align 2
> 5 main()
> \ main:
> 6 {
> 7 static int i = 1;
> 8 bit_set (i,3);
> \ 000000 1F42.... MOV.W &??i, R15
> \ 000004 3FD2 BIS.W #0x8, R15
> 9 i |= (1<<3);
> \ 000006 B2D2.... BIS.W #0x8, &??i
> 10 i++;
> \ 00000A 9253.... ADD.W #0x1, &??i
> 11 while(1);
> \ ??main_0:
> \ 00000E FF3F JMP ??main_0
> 12 }
>
> \ In segment DATA16_I, align 2, align-sorted
> \ 000000 REQUIRE ?cstart_init_copy
> \ ??i:
> \ 000000 DS8 2
> \ 000002 REQUIRE `?`
>
> \ In segment DATA16_ID, align 2, align-sorted
> \ `?`:
> \ 000000 0100 DC16 1
>
> ----- Original Message -----
> From: Rachel Adamec
> To: m...
> Sent: Saturday, April 28, 2007 3:38 PM
> Subject: RE: [msp430] expression has not efect
>
> what's the warning?
>
> could it be something about the previous line that doesn't assign a value
> to
> anything?
>
> Rachel Adamec
> Norristown, PA USA
>
> -----Original Message-----
> From: m... [mailto:
> m... ] On Behalf Of
> Daniel H. Sagarra
> Sent: Saturday, April 28, 2007 2:20 PM
> To: m...
> Subject: [msp430] expression has not efect
>
> Some one know why the compiler warring at: set_bit (i,3);
> in the folowing code ?:
>
> #define bit_set(a,b) ((a) | (1 << (b)))
>
> main()
> {
> static int i = 1;
> bit_set (i,3); // expression has no efect
> i |= (1<<3);
> i++;
> while(1);
> }
>
>
>
>
>
> ----------------------
> E-mail clasificado por el Idenfificador de Spam Inteligente. Para
> modificar la categor clasificada acceda a su webmail
>
> ----------------------
> Este mensaje ha sido verificado por el E-mail Protegido. Antivirus
> Actualizado en 27/04/2007 / Versi: 5.1.00/5019
>
>
>
>
>