>I have now learned that goto is not an evil statement but it can be used in an >evil way. There is actually a reason why it does exist. GOTO is evil in the same way that alcohol is evil. Using either indiscriminately and extensively will always lead to disaster= .. Used carefully and in moderation both can be beneficial. My personal rule is that the GOTO and its target should both be visible on the screen at the same time. On 6 April 2014 23:14, Ruben J=F6nsson wrote: > > > Ruben J=F6nsson schreef op 06-Apr-14 2:24 PM: > > > Regarding goto: > > > > > > Here is a piece of code from the demo app for the TCP/IP stack from > Microchip: > > > > > > ... > > > // Read all browser POST data > > > while(curHTTP.byteCount) > > > { > > > // Read a form field name > > > if(HTTPReadPostName(curHTTP.data, 6) !=3D HTTP_READ_OK) > > > goto ConfigFailure; > > > > > > // Read a form field value > > > if(HTTPReadPostValue(curHTTP.data + 6, sizeof(curHTTP.data)-6-2) > !=3D > > > HTTP_READ_OK) > > > goto ConfigFailure; > > > > > > //some more test cases here which all jumps to ConfigFailure on > failure > > > } > > > > > > // do something if all is ok here > > > return HTTP_IO_DONE > > > ConfigFaulure: > > > // Do something else on failure here > > > return HTTP_IO_DONE > > > } > > > > > > Of course this could be handled without goto but it seems like a good > way to > > > handle this with a goto here. I guess it all depends on how the goto > is used. > > > > > > > > > > IMO this would be better written either > > > > - with the while and tests in one function, with 'return failure' > > instead of the goto's; call this function from another function, which > > does the 'postprocessing. > > > > or > > > > - with 'status =3D failure; break;' at the goto's, and a single if at t= he > > end which tests the status. > > > > Wouter > > I am not sure that I agree that this would be better written in this case= .. > The > first option makes the code harder to read since I have to go and look up > the > function to know what it is doing. I also have to pass along some variabl= es > and/or pointers and of course calling the function which introduces > overhead on > the compiled code (not by much but still...). > > I would probably use the second option myself, mostly because I have been > taught that goto is an evil statement in C. However, here it introduces o= ne > more variable that has to be initialized, a break that could be forgotten > (and > only discovered if all if statements are tested against a failure result)= .. > It > also makes the code harder to read since I have to go down and check what > happens after the break. break is actually just a goto anyway but with th= e > difference that it is not always obvious where it goes too or what it > does. A > goto with a meaningful label on the other hand... > > I have now learned that goto is not an evil statement but it can be used > in an > evil way. There is actually a reason why it does exist. > > I am not trying to convince you or anyone else to start using gotos in C > but > just saying that sometimes it does make sense to do so and it may be the > best > option (such as in this case, in my opinion). > > /Ruben > > > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > --=20 __________________________________________ David C Brown 43 Bings Road Whaley Bridge High Peak Phone: 01663 733236 Derbyshire eMail: dcb.home@gmail.com SK23 7ND web: www.bings-knowle.co.uk/dcb --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .