I always thought that dogmatic structural code only allowed for a single return statement (or none, if it is a void function) - https://hackerchick.com/religious-war-48293-single-vs-multiple/
These are rather dogmatic opinions I never took helpful in C. If have an alarm before loop block start and no extra to handle I see more than fine to handle it at beginning having several return/end points.
However, in OOP languages, that is more serious issue and thus that should basically be strict rule after object is created.
I worked on one company where that was enforced, with the most often given reason being that you avoid multiple different blocks to release resources (the repeated fclose() calls in the above code)
I suppose the same company allowed labels, goto, endless loops, multiple continue and breaks? That certainly break fundamental rule about structural programming, which is paradox. I would left that company immediately.
And then there is also the mantra that conditional expressions shouldn't have any side effects. For example this pseudo-code might be buggy, depending on the target language semantics:
WHILE timer_not_expired AND read_a_record(file, buffer) DO
...
END WHILE
This is fine in C, but the Pascal equivalent would be buggy as all parts of the expression are guaranteed to be evaluated.
In modern Pascal implementations, as Delphi, there is compiler directive for short-circuit evaluation. Specifically in Delphi, it is set to true by default.
In general, with unknown short-circuit evaluation status for language implementation and with one or more function call and/or even assigning (in C like languages), it is rather undefined what compiler will optimize to be evaluated first. Thus it is advisable to avoid that kind of expressions and handle inside the block.
I am sure that we both agree that that is 'correct' but clunky.
If that is the required rule, then generally yes.
However, you do not need new_record in this case and multiple assignments. Or can be used do-while loop when suitable. As well, initial value of rtn should be FAILURE, but that is obviously unintentional mistake...
Then again, proper handling depends from situation to situation.