This is the mail archive of the
mailing list for the GCC project.
Re: [libfortran] Patch for pr 15328
- From: Janne Blomqvist <jblomqvi at cc dot hut dot fi>
- To: Bud Davis <bdavis9659 at comcast dot net>
- Cc: gfortran <fortran at gcc dot gnu dot org>, gcc-patches at gcc dot gnu dot org
- Date: Sat, 15 May 2004 12:01:16 +0300
- Subject: Re: [libfortran] Patch for pr 15328
- References: <firstname.lastname@example.org>
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. */
+ 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
> 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.