On Wed, Dec 29, 2010 at 09:30:05AM -0500, Olin Lathrop wrote:
> PETER ONION wrote:
> >>> if(diff >=3D 0)
> >>>      byte =3D  0;
> >>> else
> >>>
> >>> {
> >>>      byte =3D  8;
> >>>      diff =3D - diff;
> >>> }
> >
> > The ";" just terminates the "if true statement".
>=20
> But if a semicolon doesn't end the IF statement, what does end it
> unambiguously?

Nothing. The ambiguity is resolved by the rule "closest open if statement".
You have to expliticly use braces to shield an inner if statement from an
outer else. Two examples:

if (outer)
   if (inner)
      oneline =3D 0;

  else // Placed "ambiguously" on purpose
    elseval =3D 1

Since there are no braces to direct assignment, the else is attached to the
closest open if statement, which in this case is the inner one.

It's always better to be explicit about it. Here's how braces can be used
to force the else to be attached to the outer if:

if (outer) { // Forcing brace
   if (inner) { // Brace not required, but I always put it anyway
      oneline =3D 0;
   } // This does not close the inner if, simply terminates the if part
} // Forcing brace. This does close the inner if because it closes the if
  // part of the outer if. So we are in outer if space at this point.
else { // This else is attached to the outer if
   elseval =3D 1;
}


>  Or put another way, what if there was a outer IF not shown
> above, and ELSE was meant to be part of it, not the IF shown.  How would =
you
> then end the IF shown so that the ELSE would not be part of it?
>=20
> For example:
>=20
>   if (outer_condition)
>       if (inner_condition) count=3D0; //TRUE case of outer IF
>     else
>       do_something();               //FALSE case of outer IF
>=20
> How do you "end" the second IF so that the ELSE belongs to the first IF?=
=20

See above.

> If
> what you're saying above is true, then the only way to do this is to put =
the
> second IF inside brackets?  I suppose that's at least consistant, but jus=
t
> asking for easily made mistakes.  Worse, what I wrote above would not be
> interpreted as intended, but would be perfectly legal and not generate an=
y
> compile error.

Exactly. But unfortunately both by custom and by standard, C is set in
stone and cannot be changed at this point.=20

>=20
> This is why it seemed logical that the ";" would end the inner IF.  But i=
f
> what you're saying is true (I expect it is, as I said, I'm no C whiz), it=
's
> hard to imagine what was going thru K&R's minds when they designed the
> syntax.
>=20

Kernighan's primary concern at the time was compactness of expression. So
making braces optional and having a default rule generated the most compact
source.

As I said in my other post, I use and explicit ENDIF construct, which
completely disambiguates the situation.

> This would be yet another reason to religiously use brackets in IF
> statements.  That's probably why I never bumped into this in real code.

I do the same. Braces all the time, even when not required.

BAJ

--=20
Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjeff
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.