![]() ![]() Your program of #1, cast into fixed format source, runs with OpenWatcom F77 1.9 and prints "d'oh", however, so the implementation may not quite follow that quotation. 15 a restriction on assigned GOTO within the range of a DO loop. The IBM VS Fortran II manual at describes on p. If they differed from those that IFort gives you, you would have some digging to do! Nevertheless, it may be useful to run your unmodified program with Watcom F77 to establish a baseline set of results. Unlike the computed GO TO statement, execution does not continue with the next statement. If it is not in the list, an error will occur when the assigned GO TO statement is executed. If a list of statement labels is present then the statement label assigned to i must be in the list. ![]() What I do not understand is why all the manuals of all the mentioned compilers do not say anything clear about this issue, and remain as indetermined as the standard is.Į745200, I understand your concerns, and here is something that you may find useful. This totally discards the option that in case of an assigned value not present in the list the program would execute that statement (for that compiler).Īt this point, although my experience is limited to a buch of different compilers, I would assume that - possibly due to the incompleteness of the specification - the list-of-labels feature has never been implemented as a mandatory restriction on the value of the assigned label, and it is always ignored, with the exception of gfortran by which it is dealt with as a syntax error. they both bahave as depicted in the example above).Īdditionally, at compile time, VSFORTRAN clearly signals an unlabelled statement strictly following the ASSIGNED GOTO as unreachable code. I'll give you another piece of information: I was able to verify that the optional list of lables is ignored in VSFORTRAN and in Portland Fortran too (i.e. What purpose is (was) served by repeating a label in the list? "A label may appear more than once in the label list of an assigned GO TO statement". There is one more statement in the standard about assigned go to-s that I do not understand: As of now, I think that he should simply ignore the label lists in his code while doing the code updating. He is handicapped by not knowing (except by trial and error) what the current behavior is, since the documentation does not stipulate it. What should the OP do? He is trying diligently to get rid of assigned go to statements in old code, and he wants the code to function in the same way as it has in the past. I can tell you that we're not going to change the behavior of this usage. In the present implementation, that purpose is not met. The only meaningful purpose of the label list, as far as I can see it, is to modify the behavior of the assigned GOTO when the variable has a value that is not in the list. I'd be a bit uncomfortable about ignoring the ASSIGN, though I suppose one could treat this similar to SELECT CASE, where if there is no match and no CASE DEFAULT, it just flows past the SELECT block. Since the standard doesn't provide an interpretation for this usage, anything could happen. ![]() What is a reasonable response from any compiler that still supports assigned go to statements and supports the optional label list when the assigned value is not one of the values in the list? I suggest that control should go to the next executable statement. On the other hand, if the requirement is satisfied, the assigned GOTO behaves in the same way whether or not the label list is provided, so the effect of having a label list is either "nothing" or "undefined", and the label list has little reason to exist unless a vendor-provided extension defines what happens when the assigned value is not in the list. ![]() This is quite a strange case where the Fortran standard says ".the value currently assigned to the variable should be one of the labels in the list if the list is specified", but says nothing about what should happen if that requirement is violated, so the catch-all rule of "undefined behavior" may be expected to apply. I had not known about the optional label list of assigned GOTO statements until I saw this thread. ![]()
0 Comments
Leave a Reply. |