[libfortran] Patch for pr 15328

[Janne Blomqvist]

On Fri, May 14, 2004 at 06:58:16PM -0500, Bud Davis wrote:
> In the routine finalize_transfer we have current_unit->s, which is of
> type stream*, which gets changed to type unix_stream in routine flush..

Yep, that's why I made the public interface function for it in
unix.c. BTW, the problem with having to declare fd_flush non-static
was resolved by deleting some .o files before compiling, so the
correct patch for unix.c is only the public interface function (now
with a short comment):

===============================================================

diff -c3 -p unix.c.orig unix.c
*** unix.c.orig Fri May 14 21:58:55 2004
--- unix.c      Sat May 15 11:38:30 2004
*************** is_seekable (stream * s)
*** 1395,1400 ****
--- 1395,1409 ----
  }
  
  
+ /* flush()-- Given a stream, try to flush it. Return SUCCESS or FAILURE. */
+ 
+ try
+ flush (stream *s)
+ {
+   return fd_flush( (unix_stream *) s);
+ }
+ 
+ 
  /* How files are stored:  This is an operating-system specific issue,
     and therefore belongs here.  There are three cases to consider.
  


================================================================


> My C is poor, but I think this is dangerous.  It works because the first

Of course it's dangerous, it's C after all. ;-)

> item in a unix_stream is a stream, but fd_flush will be updating items
> in current_unit->s which do not exist, since it is not a unix_stream.

This is a very valid concern. What makes this work is that we never
malloc() a stream directly, nor do we do any pointer arithmetic on the
stream pointer. When we want a stream, we call a function (defined in
unix.c) which creates a unix_stream, does some stuff and typecasts the
unix_stream to a plain stream which is returned. Thus the unix_stream
data is always found in memory just behind the stream.

If you look at unix.c you can see that typecasting from stream to
unix_stream is done all over the place, so if my code bombs because of
incorrect typecasting there sure is a lot of other code that needs
fixing too.

> I think we need a way of mapping the a stream to a specific unix_stream.

I think the idea is that unix_stream is OS specific, so the use of it
is isolated to the unix.c file. So, it's a good thing that most io
functions no nothing about unix_stream.

> Then again maybe I am just confused :)

Who isn't, when looking at C code. That's why we're implementing a F95
compiler, right? *ducks* ;=)

> Welcome aboard.

Thanks.


-- 
Janne Blomqvist