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??
expression has not efect
Started by ●April 28, 2007
Reply by ●May 2, 20072007-05-02
Reply by ●May 2, 20072007-05-02
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??
> 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??
Reply by ●May 3, 20072007-05-03
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
>> 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
Reply by ●May 3, 20072007-05-03
[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
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
Reply by ●May 4, 20072007-05-04
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!!
> 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!!
Reply by ●May 4, 20072007-05-04
> 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!!
> 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!!
