Is goto Still Considered Harmful?

[James Kuyper]

["Followup-To:" header set to comp.lang.c.]

I don't see how (var = true) can have a portability issue, where
var is of type bool, and the result is not converted in any way,
but only used as a control expression for some conditional thing

All this stuff with the assignment seems to be clouding the
central issue of this subthread, which is that if var has type
_Bool and internal representation B'00000010' what happens
when

if(var)
{
x = 1;
}
else
{
x = 0;
}

is executed? Does the standard allow bits 1:7 to be padding
bits ...

Yes. It also allows bits 0 and 2-7 to be padding bits. It's really quite
remarkable how little the C standard constrains the ways it can be
implemented.

... so that var tests as false and x = 0, or does it allow
all bits to be value bits ...

Also yes.

... so that var, being nonzero, tests
as true so x = 1, or does it allow B'00000010' to be a trap
value so that exceptional behavior can happen? ...

Yes, that is also permitted.

... Is any of
these behaviors required?

The width (number of value bits) of _Bool is not mandated by the
standard, though it must be >= 1 to satisfy 6.2.5p2. There is also
nothing preventing it from having trap representations - but the fact
that they are trap representations must be determined by padding bits.
As an unsigned type with N value bits (regardless of the value of N),
_Bool must be able to represent every value from 0 to 2^N-1, (6.2.6.2p1)
so for every possible combination of value bits, there must be at least
one non-trap representation containing that combination.

 

[Keith Thompson]

On 03/14/2014 12:36 PM, James Van Buskirk wrote: [...]

Part of the premise of this subthread is that both left and right
operands have the same intrinsic type, _Bool. See above.
In n1124.pdf, section 6.3 I read:

n1124.pdf is quite old; I'm not sure which version of the standard it
describes. I don't think anything relevant to this discussion has
changed recently, but uou should still get n1570.pdf, which is almost
identical to the current standard.

N1124 consists of the C99 standard with the first two Technical
Corrigenda merged into it. N1256 is similar, but includes all three
TCs.

N1570 is a draft of the C11 standard, published shortly before the
official standard was released. There are only a few differences.

There's probably no point in using N1124, but N1256 might be more useful
than N1570 if you're using a compiler with no support for any of the
changes in C11.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

 

[David Brown]

That's completely bonkers! Of course it will give different warnings on
different optimisation settings. But so what? No-one is asking it to
warn about /all/ unreachable code (that's solving the halting problem).
But warning about some of it is better than warning about none. Surely!

I believe the problem is that when you optimise, a lot of code can be
eliminated. For example, if you have this:

#define startX 10
#define stopX 20

static inline int abs(int x) {
if (x < 0) {
return -x;
} else {
return x;
}
}

void foo(void) {
for (int x = startX, x < stopX, x++) {
printf("%d: %d\n", x, abs(x));
}
}


When gcc used to have the "-Wunreachable-code" warning, this would give
a warning on the "return -x" line when optimising - because that line
/is/ unreachable in this code. But such a warning is extremely
unhelpful here - it is not uncommon to write code that will not actually
be executed because you write your functions in general terms.

Without being privy to the gcc maintainers' thoughts at the time (I
haven't read the mailing lists), I expect it was very difficult to find
a way to distinguish between such intentional unreachable code, and
unintentional unreachable code. Note that even the duplicate "goto
fail" line could occur as intentional code as a result of pre-processing
and macros (especially combined with the poor bracketing style of the
code's authors).

I am always a fan of more warnings, and I would have preferred it to
remain an option (but not in -Wall) - perhaps it was not practical to
maintain it with useful enough results.

 

[Nasser M. Abbasi]

It never was.

Remember, Dijkstra wasn't an actual developer. He never worked on any software
project of consequence. (Oh, pardon me, the THE system.)

I would guess that this is the case of almost all computer science
professors.

--Nasser

 

[Ben Bacarisse]

I would guess that this is the case of almost all computer science
professors.

I think you might be surprised, though you can always make it true by
judicious definition of "consequence". The objectives of software
developed as part of a research project and those of software developed
for use "in the wild" are different, but both are of consequence.

 

[Stefan Ram]

I think you might be surprised, though you can always make it true by
judicious definition of "consequence". The objectives of software
developed as part of a research project and those of software developed
for use "in the wild" are different, but both are of consequence.

Donald E. Knuth wrote TeX decades ago. It is still the most
commonly used typesetting system for mathematics and similar
realms. He wrote it using his WEB literate programming
system (it was named »WEB« before the invention of »the
World Wide Web«) that is based on the programming language
Pascal, which in turn was created by another scholar. The
algorithms of Knuth's »The Art of computer programming«
surely are used widely in many software systems today. And
if not, people often regret it, as did online-casinos with
insufficient random-number generators.

Persons change from research jobs into non-research jobs.
Google, Microsoft and Sun had all hired people known for
their research in programming languages and, in the other
directions, practioners become researchers or teachers.

 

[Stephen Sprunk]

... My impression was that assignment between variables of
the same integer type in C was to copy all the bits, and that the
result of the assignment was the value that the variable got
assigned.

That is not true; assignment is by value, after any required
conversions, rather than by representation.

Conceptually, an assignment to _Bool like this:

_Bool x = 2;

is implemented like this:

_Bool x = !!(2);

The '!' operator looks at all of its operand's value bits, not just the
lowest one, so any nonzero value gets converted to _True.

S

 

[David Brown]

Ah yes, I do see what you mean. As you say, a general purpose function
that's being used in a very constrained set of circumstances.

OTOH, it is warning you that you are doing a pointless abs call, but in
a fairly indirect way.


Yes, I may have been a bit premature, thanks!

The world of C and C compilers is full of subtle issues like this.
Whenever you think "they must have been mad to do that", there is
probably some reason you are missing!

 

[Seebs]

But of course, the imbeciles will, again, do it in a completely different way
from GCC, like inline and variadic macros, so then, in turn, GCC will have GNU
boolean constants (warned about, if not outright disabled, in -pedantic mode),
and ISO boolean constants.

In the case of inline, there were multiple competing implementations of
inline functions. May have been something similar for variadic macros.

Also, back in the 90s, there was pretty poor communication between gcc
people and the ISO committee. (My impression at the time was that this was
not a case with one party clearly at fault, but rather, one of those
complicated social interactions that programmers are so bad at.)

So far as I know, these days, things are much friendlier. Of particular
note, the gcc manual no longer blames ANSI for the behavior of backslashes
in #include directives. In gcc 2.95 or so and earlier, they said:
Thus, `#include "x\n\\y"' specifies a filename containing
three backslashes. It is not clear why this behavior is
ever useful, but the ANSI standard specifies it.
This wasn't actually true, but it stayed in the docs for ages for reasons
not known to me. It appears to be fixed by gcc-3.1 or so.

-s

 

[Lynn McGuire]

not for me

Me either. I just want to reduce our
usage of it.

Lynn

 

[Lynn McGuire]

I didn't see anything in that article that hasn't been said a zillion
times before. I'll note that, although the code shown was C, the goto
statements were used in very much the same way as most of the few gotos
that I use in my Fortran code - for an error exit.

We still have hundreds of thousands of lines of
F66 code in our app. I wish most of the gotos
would just go away. I rip a few out whenever I
get a chance but the risk of creating new bugs
is very high.

Lynn

 

[James Kuyper]

On 03/18/2014 05:08 PM, Seebs wrote:
....

Also, back in the 90s, there was pretty poor communication between gcc
people and the ISO committee. (My impression at the time was that this was
not a case with one party clearly at fault, but rather, one of those
complicated social interactions that programmers are so bad at.)

One of the key problems seemed to be that there was little or no overlap
between those two groups. While many ISO committee members were familiar
with gcc, I believe that when C99 was being created, none of them were
gcc developers, and therefore they did not know any details about how it
was implemented. Committee membership is a volunteer activity (and least
in ANSI, the US member of the ISO C committee, which has a greatly
disproportionate amount of influence on the C committee), and I get the
impression that volunteers are seldom, if ever, rejected. Therefore, the
absence of gcc developers from the committee has to be attributed to a
failure by those developers to volunteer.

Full voting membership is moderately expensive for an individual,
particularly including the travel requirements, but it's not expensive
enough to prevent many members from being individuals representing only
themselves. Full membership is cheap by the standards of any
organization of reasonable size, and I believe that gcc has a fairly
large number of developers, with international coverage - for most of
the committee's meetings, I'd expect gcc to have at least one developer
within driving distance of the meeting. Even a single non-voting member
of the committee who was a gcc developer would probably have
substantially improved the gcc compatibility of the resulting standard.

 

[Geoff]

We still have hundreds of thousands of lines of
F66 code in our app. I wish most of the gotos
would just go away. I rip a few out whenever I
get a chance but the risk of creating new bugs
is very high.

Lynn

If it ain't broke, don't fix it, unless you can afford to replace it.



The original concept and intent of avoiding goto was to make
comprehension and maintenance easier. If the code works and never
needs maintenance or if any maintenance of the code isn't made
difficult by its spaghetti shape, then there is no reason to refactor
unless there is confidence that regression testing will reveal any
errors that might arise as a result.

 

[Terence]

We still have hundreds of thousands of lines of
F66 code in our app. I wish most of the gotos
would just go away. I rip a few out whenever I
get a chance but the risk of creating new bugs
is very high.

Lynn

I repeat, just use a simple tool.
One option is to use Alan Miller's code to go straight to F90.
There are others.
But you are in the unique position of being able to retest at any step into
which you break the project up.

 

[James Kuyper]

....

If it ain't broke, don't fix it, unless you can afford to replace it.



The original concept and intent of avoiding goto was to make
comprehension and maintenance easier. If the code works and never
needs maintenance or if any maintenance of the code isn't made
difficult by its spaghetti shape, then there is no reason to refactor
unless there is confidence that regression testing will reveal any
errors that might arise as a result.

I would guess that "whenever I get a chance" refers to when maintenance
is needed for other reasons; that's the same rule I use when determining
whether to make stylistic improvements to working code. And it's pretty
plausible that any code that old is indeed difficult to maintain because
of its spaghetti shape.

 

[BartC]

On 03/18/2014 08:36 PM, Geoff wrote:

I would guess that "whenever I get a chance" refers to when maintenance
is needed for other reasons; that's the same rule I use when determining
whether to make stylistic improvements to working code. And it's pretty
plausible that any code that old is indeed difficult to maintain because
of its spaghetti shape.

If it really was spaghetti code, then yes.

But if the gotos were used sensibly to construct missing control statements,
then it might be possible to derive those by some analysis.

 

[James Kuyper]

If it really was spaghetti code, then yes.

But if the gotos were used sensibly to construct missing control statements,

Such code can still be hard to maintain - there's a legitimate reason
why those control statements were added to later versions of Fortran.

 

[Lynn McGuire]

I repeat, just use a simple tool.
One option is to use Alan Miller's code to go straight to F90.
There are others.
But you are in the unique position of being able to retest at any step into
which you break the project up.

We are very slowly moving our kernel calculation
code to C++. Very, very slowly.

Lynn

 

[Lynn McGuire]

If it really was spaghetti code, then yes.

But if the gotos were used sensibly to construct missing control statements, then it might be possible to derive those by some analysis.

I was working on a 6,000 line subroutine the other
day with a goto from line 5000 to line 2000. Talk
about a context change for a looping mechanism.

Lynn

 

[Malcolm McLean]

Persons change from research jobs into non-research jobs.
Google, Microsoft and Sun had all hired people known for
their research in programming languages and, in the other
directions, practioners become researchers or teachers.

Higher education is done by people with research interests. So it's natural
for the final stages of higher education to consist partly or wholly of
research. Most people then move on to jobs outside the academic sector.