Re: [patch, fortran] PR22539 implement FSEEK intrinsic

[Daniel Franke <franke dot daniel at gmail dot com>]

On Tuesday 01 May 2007 19:35:02 Brooks Moses wrote:
> > +/* FSEEK intrinsic */
> >
> > +extern void fseek_sub (int *, GFC_IO_INT *, int *, int *);
> > +export_proto(fseek_sub);
> > +
> > +void
> > +fseek_sub (int * unit, GFC_IO_INT * offset, int * whence, int * status)
> > +{
> > +  gfc_unit * u = find_unit (*unit);
> > +
> > +  if (status) *status = 0;
> > +
> > +  if (u == NULL || !is_seekable(u->s))
> > +    {
> > +      if (status) *status = -1; /* EBADF */
> > +    }
> > +  else if (*whence == 0)
> > +    sseek(u->s, *offset);                       /* SEEK_SET */
> > +  else if (*whence == 1)
> > +    sseek(u->s, file_position(u->s) + *offset); /* SEEK_CUR */
> > +  else if (*whence == 2)
> > +    sseek(u->s, file_length(u->s) + *offset);   /* SEEK_END */
> > +  else if (status)
> > +    *status = -1;  /* EINVAL */
> > +}
>
> I don't see how this returns a nonzero status if *offset is outside the
> limits of the file such that the sseek fails.  How does that work?

It does not fail. 
The sseek macro, eventually, calls lseek(2):

  "The lseek() function allows the file offset to be set beyond the end of
  the file (but this does not change the size of the file).  If  data  is
  later written at this point, subsequent reads of the data in the gap (a
  "hole") return null bytes ('\0') until data is  actually  written  into
  the gap."


> Also, what happens if sseek fails and STATUS isn't supplied; is this a
> runtime error, or a silent failure?

If an error condition is met, no seek is performed. Possible errors of 
sseek/lseek are:

 * EBADF:     bad file descriptor (u == NULL)
 * EINVAL:    whence < 0 || whence > 2
 * EOVERFLOW: offset to large (handled by largest int kind GFC_IO_INT)
 * ESPIPE:    file not seekable (!is_seekable(u->s))

None of these conditions will ever be propagated to lseek. G77 does not error 
out if no label is specified. Nonetheless, a runtime error might be useful in 
some cases. Maybe Jerry has a more definite opinion on this?!

I will clarify the documentaion according to your suugestions.

Regards
	Daniel