[Patch, libgfortran] PR 25561 Part 0.9/2 Get rid of alloc stream

[Jerry DeLisle]

Janne Blomqvist wrote:
> Hello,
> 
> this is an almost complete patch for part I of getting rid of the alloc
> stream facility (the low level libgfortran I/O stuff). The patch
> converts all users of salloc_* to the sread/swrite/sseek interface, with
> the exception of write_x(). The exception is an issue with T/TL edit
> descriptors, and as it turns out these don't work correctly now either,
> see PR 36142. See the PR for some ideas on how to solve it.
> 
> After this patch and the T/TL fix is in, I plan to continue to part II,
> which means to simplify the library by getting rid of the
> {fd,mem}_alloc* functions. For external files (fd_*()) the main idea
> I've been thinking about is to replace the current buffered I/O
> implementation with C stdio. This would, IMHO, have the following benefits:
> 
> * Due to the extremely widespread usage of stdio, we can be quite sure
> there are no bugs in the buffering. And even if there are, it's the
> headache of the upstream libc. This is in contrast to our current
> implementation that does plenty of flushing to cover up bugs.
> 
> * Better performance, stdio is mature and has been tweaked over many
> years. Also lack of unnecessary flushing, see above.
> 
> * Well documented, with well defined semantics.
> 
> * When doing formatted reads, we must usually read one character at a
> time. This has a huge overhead in our current implementation. It would
> be relatively simple to use getc() here. Or actually getc_unlocked() if
> available, since we would lock the stream for the duration of a
> READ/WRITE statement (flockfile()/funlockfile()).
> 
> * Make life slightly easier for people doing mixed language programming,
> since gfortran would use the same buffering as C. And C++ with
> sync_with_stdio() or any other language whose runtime is implemented in
> terms of stdio. Of course, mixed language I/O to the same file would
> still be somewhat dangerous.
> 
> Patch is regtested on i686-pc-linux-gnu, ok for trunk?
> 
> 

My first pass at review.  There are some //commented printf statements left over 
from debugging, those should be removed.

There are a few places where you changed function declaration from static void 
to just void.  I assume that was also for debugging purposes.?

In mem_read you introduced a variable myerror and are doing some things there. 
Please clarify what that is about.

Generally, the patch looks good.  Just need to get some bugs out.

I get three NIST regressions:

3 runtime errors
FM111 has NIST regression.
FM406 has NIST regression.
FM903 has NIST regression.

The two test cases in PR36131 fail.

fmt_t_7.f fails, but that is expected, maybe we can fix it now.

Regards,

Jerry