Is there a value in having a subroutine called, for example,
"set_var_val_ret" that takes a var, sets it to a value, and returns another
value?

E.g. rather than writing 

 If /* Stuff */ && (got_num_colon = TRUE) && /* more stuff */ {

you write 

If /* Stuff */ && set_var_val_ret(got_cum_colon, TRUE, TRUE) && /* more
stuff */ {

and so avoid both the warning/error from the compiler, and more importantly
the subtle point about the conditional continuing to evaluate due to the
value of the assignment being returned. I don't think it would be much of a
performance hit over the simply assignment. A good compiler would probably
optimize it back to that anyway.

Or set_var_val_stop and set_var_val_go_on.

--
James.

-----Original Message-----
From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf Of
William "Chops" Westfield
Sent: Tuesday, March 11, 2008 18:49
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] Mixing MPASM and C (Hi-Tech PICC)


On Mar 11, 2008, at 9:49 AM, Walter Banks wrote:

> Double braces don't solve the underlying problem


We had this gem (I think I've sanitized it enough for "the public")

     if (match_number(csb, 0, MAXUSHORT, &i, var2, flags, NULL) &&
	match_char(&csb->line[csb->line_index], &i, ':') &&
	((got_num_colon = TRUE)) &&	/* Remember we got "<number>:" */
	match_number(csb, 0, MAXULONG, &i, var3, flags, NULL) &&
	match_whitespace2(...)) {
	/* Stuff */
	return;
     }

No amount of multiple parens made a new compiler happy about that line
with "got_num_colon" in it.  And there was about a 50% chance that the
person fixing it would fix it wrong, even with the comment...

BillW

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist