> For example:
>
>   if (outer_condition)
>       if (inner_condition) count=0; //TRUE case of outer IF
>     else
>       do_something();               //FALSE case of outer IF
>
> How do you "end" the second IF so that the ELSE belongs to the first IF?  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 just
> asking for easily made mistakes.  Worse, what I wrote above would not be
> interpreted as intended, but would be perfectly legal and not generate any
> compile error.
>
> This is why it seemed logical that the ";" would end the inner IF.  But if
> 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.
>
> 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.
>
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> (978) 742-9014.  Gold level PIC consultants since 2000.

> PETER ONION wrote:
>  
>>>  Worse, what I  wrote above would not be
>>> interpreted as intended, but would be perfectly  legal and not
>>> generate any compile error.
>>>      
>> Indeed, but who's fault is that ?  You wrote valid C and that's
>> really all the compiler can check for.  If your C code doesn't
>> do what you expected it to do then it's because you don't understand
>> the C syntax and that's not the compiler's fault ! ;-)
>>    
>
> It's not about "fault", and in any case it can't be the compiler's since
> it's just following the rules of the language.  Of course it's on the
> programmer to know the syntax of the language, but there is also good and
> bad syntax design.
>
> In this case the syntax allows a easily made error to still result in legal
> code but to not be interpreted as intended.  Programmers will always come up
> with more clever errors than a language designer can and should account for,
> but a measure of good language design is how much common and
> should-be-anticipated errors get caught as illegal syntax.  A great example
> is the really irresponsible C-ism "if (i=1)...".  While the error is
> technically the programmers, the syntax rules are just asking for humans to
> make that mistake.
>
> In these two cases at least, Pascal gets it a lot more right than C.  In
> Pascal:
>
>   if outer_condition then
>       if inner_condition then count := 1;
>     else
>       ...
>
> Would generate a syntax error because the ";" ends the IF statement and ELSE
> therefore is not valid there.
>
> In the second case, the assignment operator is ":=" whereas "=" is a
> statement of equality:
>
>   if i = 1 then ...
>
> does exactly what most people reading it would think.  If you actually wrote
>
>   if i := 1 then ...
>
> then you'd get a compile error since a assignment statement isn't allowed as
> the condition expression of a IF statement.
>
> Language design *does* matter.  Unfortunately C is badly designed but so
> many people have gotten used to it they have become blind to the problems..
>
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> (978) 742-9014.  Gold level PIC consultants since 2000.
>  

>  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?
>
> For example:
>
>   if (outer_condition)
>       if (inner_condition) count=0; //TRUE case of outer IF
>     else
>       do_something();               //FALSE case of outer IF
>
> How do you "end" the second IF so that the ELSE belongs to the first IF?

>
> In these two cases at least, Pascal gets it a lot more right than C.  In
> Pascal:
>
>   if outer_condition then
>       if inner_condition then count := 1;
>     else
>       ...
>
> Would generate a syntax error because the ";" ends the IF statement and ELSE
> therefore is not valid there.
>
> In the second case, the assignment operator is ":=" whereas "=" is a
> statement of equality:
>
>   if i = 1 then ...
>
> does exactly what most people reading it would think.  If you actually wrote
>
>   if i := 1 then ...
>
> then you'd get a compile error since a assignment statement isn't allowed as
> the condition expression of a IF statement.

> On Wed, Dec 29, 2010 at 12:07 PM, Byron Jeff <@spam@byronjeffKILLspammail.clayton.edu> wrote:
> > BTW I would allow for fallthrough, but simply not make it the default. It
> > would have been simple to have fallthrough occur with the use of the
> > continue statement. In my view the last snippet should be written as:
> >
> >
> > choice = 1;
> > switch (choice) {
> >   case 1: continue;
> >   case 2: continue;
> >   case 3: printf("1,2, or 3 was picked\n");
> >           break;
> >   default: printf("other was picked\n");
> >           break; // Unneccessary but often put in for consistency.
> > }
> >
>
> I'm not sure if you've thought this through fully. The 'continue'
> statement is for going to the next iteration of a loop. Adding it's
> use in a case statement would make ambiguous cases (no pun intended)
> such as:
>
> while(inbyte = getbyte() )
> {
>   switch(inbyte)
>     {
>     case 1:
>       ....
>       continue; // Go to next case or next iteration of loop?
>     case 2:
>        ...
>      };
> }

> The only argument that holds water is that since ranges are not
> allowed,
> the default fall through allows multiple cases to share the same code:
>
> choice = 1;
> switch (choice) {
>    case 1:
>    case 2:
>    case 3: printf("1,2, or 3 was picked\n");
>            break;
>    default: printf("other was picked\n");
>            break; // Unneccessary but often put in for consistency.
> }

>
> > BTW you didn't even get to the one that just sticks in my craw:
> >
> > The default drop through action of cases in the switch statement.
>
> Yeah, that's another good one.  I totally agree the default should be to end
> the switch, not fall thru to the next case.  The C SWITCH is just a computed
> GOTO, not a real selection of multiple cases as the syntax would lead a
> casual observer to believe.  If they had named it MULTIJUMP or something, it
> wouldn't bother me so much, but then I'd still want a real multi-case
> statement.
>
> By the way, the Pascal CASE statement does work as you describe.  For
> example:
>
>   choice := 1;
>   case choice of
> 1:  writeln ('1 was picked');
> 3:  writeln ('2 was picked');
> 3:  writeln ('3 was picked');
> otherwise
>     writeln ('Other was picked');
>     end;
>
> would only result in "1 was picked" to be written.  You don't have to be a
> Pascal whiz to have a pretty good idea what the above code does.

>
> > The only argument that holds water is that since ranges are not
> > allowed,
> > the default fall through allows multiple cases to share the same code:
> >
> > choice = 1;
> > switch (choice) {
> >    case 1:
> >    case 2:
> >    case 3: printf("1,2, or 3 was picked\n");
> >            break;
> >    default: printf("other was picked\n");
> >            break; // Unneccessary but often put in for consistency.
> > }
>
> Pascal gets around it this way:
>
>   case choice of
> 1, 2, 3: writeln ('1, 2, or 3 was picked');
> otherwise
>     writeln ('Other was picked');
>     end;
>
> In other words, you can't put a bunch of cases in a row and fall thru, but
> you can give each case multiple target values.  I think that addresses your
> concern adequately enough.

>
> > switch (choice) {
> >    case 1: continue;
> >    case 2: continue;
> >    case 3: printf("1,2, or 3 was picked\n");
> >            break;
> >    default: printf("other was picked\n");
> >            break; // Unneccessary but often put in for consistency.
> > }
>
> Something like that, although as Martin pointed out, CONTINUE already has
> another meaning.  I would be fine with this if a different and new keyword
> were used, like NEXTCASE for example.

> In my source to source translator, there is a significant section of code in
> the C back end to deal with local functions.  I emulate them by using global
> functions and explicitly passing any accessed local state down to the
> function.
>
> This can get messy with nesting.  Let's say routine A calls local routine B,
> which calls its own local routine C.  C may access a local variable of A, so
> that variable has to be passed to B just so B can pass it to C when these
> local routines are emulated with global routines.  My translator does
> multiple passes of pushing call arguments up the chain until no changes are
> made in a pass.  The result is not pretty, but it works for the C output
> language.

> Agree, any language, including C, can be improved.  C is definitely a product of
> its time and since computer sciences and applications have advanced, the
> original C is not adequate any more.  So it has evolved a bit.  
>
> If one follows all suggestions by Stroustrup, would we not get C++?  
>
> My comment was actually targeted to the specific discussions on this list as to
> which language is best.  It seems like C vs assembler vs Jal vs whatever
> discussions ignite very often and I wanted to point out that there is a right
> tool for every specific applcation.
>
> Sergey Dryga
>
> http://beaglerobotics.com
>
>
>
>  

>>> FOSS definitely helped C a lot, even before it was called that.  
>>> First there was the portable C compiler, which lasted through the  
>>> late 1980s.  Then there was gcc.
>
>> And lets not forget MAD (Michigan Algorithm Decoder) running on IBM  
>> 709 (vacuum tubes) and 7090 (solid state) in the early 1960's. It  
>> helped a lot to have Alfred E. Newman's picture on the cover. :)  
>> Then in the mid 1970's there was Basic running on a Univac 1108.
>
> I can't tell whether you're making fun of my "ancient history" or if  
> you're serious.  I claim it was in the 80s that C pulled ahead of  
> everything else, so to figure out why, you need to look at the things  
> that happened in the late 70s and early 80s.
>
> I suppose the policies of mainframe and larger computer vendors toward  
> universities had a lot to do with things.  Waterloo Fortran, Dartmouth  
> and Stonybrook Basic, Cornell PL/C, Stanford SAIL, Rutgers Pascal,  
> Penn APL, who knows how many LISP implementations...  But nothing  
> aimed at microcontrollers; there were CP/M machines, 6502 SBCs, and  
> small PDP/11s around, but I'm not aware of anyone doing language  
> development for them (I was sort of mainframe-oriented in those days,  
> so I could be mistaken.  But I certainly recall that most languages  
> for micros came from entrepreneurial hackers like Bill Gates.)  I  
> guess part of the problem was the lack of storage on a lot of those  
> micros.  Cross-compilers for mainframes weren't very interesting to  
> the people without a mainframe, and the people that did have the  
> mainframe were writing other stuff...)

> On 31/12/2010 08:45, Wouter van Ooijen wrote:
>>> If one follows all suggestions by Stroustrup, would we not get C++?
>> Stroustroup's hands were very much tied behind his back by the practical
>> wish to remain compatible with C. If he had designed C++ from scratch
>> (or even allowed more incompatibilities with C) it would have been very
>> different.
>>
> Agreed.
> AT&T crippled C++, I've read Stroustroup's original book and various
> postings over the years. C++ would not have been much compatible at all,
> but far better and most bugs and security issues from sloppy C
> programming and C style usage of C++ would not exist.