This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: RFC: Implementing FSEEK intrinsic, ErrLabel optional argument
- From: Brooks Moses <brooks dot moses at codesourcery dot com>
- To: fortran at gcc dot gnu dot org
- Date: Sun, 17 Dec 2006 01:36:43 -0800
- Subject: Re: RFC: Implementing FSEEK intrinsic, ErrLabel optional argument
- References: <4584D9A3.8070309@codesourcery.com>
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