RFC: Implementing FSEEK intrinsic, ErrLabel optional argument

[Brooks Moses]

Brooks Moses wrote:
> There's currently only one G77 intrinsic not implemented in GFortran -- 
> the FSEEK instrinsic.  The specification for this in G77 is
> 
>    CALL FSeek(Unit, Offset, Whence, ErrLab)
> 
> where ErrLab is an optional argument described as "'*label', where label 
> is the label of an executable statement."
> 
> Steve and I talked about this a bit on IRC earlier this evening, and 
> were strongly considering implementing this with the error label ignored 
> (and letting the subroutine just abort on error conditions) because of 
> the complexities involved in such a thing, but after not thinking about 
> it for a while, I realized there's already a mechanism in place for 
> handling exactly this: alternate returns from subroutines.  I should 
> have known, of course, because that's why it's "*label" and not just 
> "label".
> 
> (Admittedly, an optional alternate-return argument isn't exactly allowed 
> by the standard, but we can probably finesse it for an intrinsic.)
> 
> There aren't any existing intrinsics that have alternate returns, are 
> there?  Does anyone have any handy suggestions for how to go about 
> writing one that does?

Ok, PRs 30235 through 30237 later, and I'm beginning to think that 
Steve's suggestion is the right way to go after all.  Alternate return 
arguments are handled completely differently from other arguments (the 
expr or sym pointer in the argument list is simply NULL), and the 
instrinsics machinery doesn't have anything at all in place to deal with 
that.

Currently, PR 30237 means that if we implented FSEEK as a three-argument 
intrinsic, and someone put in a alternate-return fourth argument in 
their code, that extra argument would get ignored, which in this case is 
as close to the Right Thing as we'll get.  However, as soon as someone 
fixes PR 30237, that will break, and there will be a syntax error about 
the alternate-return argument instead.

- Brooks