4 ms·
Actually you can do that without goto's, by using do {} while loop and break: FILE *fh; char *buf = NULL; char *rv = NULL; do { fh =
by kelvich 8y ago
Actually you can do that without goto's, by using do {} while loop and break:
FILE *fh;
char *buf = NULL;
char *rv = NULL;
do {
fh = fopen(...);
if (!fh) {
report_error();
break;
}
if (fail(fseek(fh, end))) {
report_error();
break;
}
long int sz = ftell(fh);
if (sz <= 0) {
report_error();
break;
}
buf = malloc(sz);
if (!buf) {
report_error();
break;
}
if (failed(fread(fh, buf))) {
report_error();
break;
}
rv = buf;
buf = NULL;
} while(false);
if (fh)
fclose(fh);
if (buf)
free(buf);
return rv;
- acprog42 8y agoSure, that would pass the `grep -r goto ` test, but is just a more convoluted way of doing the same thing.
- coldtea 8y agoThat's fine: the intention was not to do something else, but to avoid goto while still doing the same functionality. Plus, it might be slightly more convoluted than goto, but is less convoluted than the original over-nested code, which was the intention.
- acprog42 8y agoWhich brings us back full circle to the point I was originally trying to convey: if a coding standard forces you to write more convoluted and harder-to-read code just to work around some of its rules, that is a clear failure of said standard. Fortunately MISRA seems to have gotten back some sanity in the 2012 revision compared to the one the above JPL standard is based on.
- coldtea 8y ago>Which brings us back full circle to the point I was originally trying to convey: if a coding standard forces you to write more convoluted and harder-to-read code just to work around some of its rules, that is a clear failure of said standard. Only if the "more convoluted and harder-to-read code" is worse than what the standard tries to avoid. A standard that calls for not allocating memory dynamically for example might result in less elegant code than one that does, for example, but that's not a "clear failure" since that away it avoids the uncertainty and variable runtime performance that malloc brings. I'm addressing the general claim here, that "if a coding standard forces you to write more convoluted and harder-to-read code just to work around some of its rules, that is a clear failure of said standard" -- not specifically where the particular no-goto rule was justified. A standard can be perfectly valid and good in restricting things even if that forces programmers to write "less elegant code" -- as long as this is necessary to fulfil some other objective of the standard (e.g. easy formal verification or real-time behavior).
- konstmonst 8y agoWhich muddles the intent and is worse than using goto imho
- thom 8y agoI assumed the intent was to suggest a similar structure that wouldn't raise warnings under one of these sets of coding standards.
- flyinglizard 8y agoActually it’s not the same, as using goto lets you have very natural reverse order cleanup at the exit of the function (widely used in the Linux kernel for example).
- vbezhenar 8y agoYou must prove that this loop will terminate: All loops shall have a statically determinable upper-bound on the maximum number of loop iterations. It shall be possible for a static compliance checking tool to affirm the existence of the bound.
- TheCoelacanth 8y agoSince the loop condition is the constant `false`, it should be trivial to prove that the upper bound is one iteration.