From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30362 invoked by alias); 22 Dec 2005 14:24:40 -0000 Received: (qmail 30345 invoked by uid 48); 22 Dec 2005 14:24:38 -0000 Date: Thu, 22 Dec 2005 14:24:00 -0000 Message-ID: <20051222142438.30344.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libfortran/25139] [4.1/4.2 regression] "Invalid argument" error on I/O In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "fxcoudert at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2005-12/txt/msg02343.txt.bz2 List-Id: ------- Comment #22 from fxcoudert at gcc dot gnu dot org 2005-12-22 14:24 ------- (In reply to comment #21) > new = file_position (u->s) - m - 2*sizeof (gfc_offset); > > as "2*sizeof (gfc_offset)" is the size of the green words before and after the > data and m is the size of the data. (m+2*sizeof (gfc_offset)) is the total size > of the binary record that is being skipped backwards over. Did you test that patch? Does it work? I would be very surprised if it did. You need to consider that the previous read (or salloc_r_at, to be exact) might or might not read all length bytes. So, after that call, length might be sizeof(gfc_offset), or it might be 0, or it might be something in between. You need to do something that takes into account all these cases, and that's what I thought my patch did. I don't have time now to make all the reasonning again, but I just wanted to underline that issue so that you're aware of it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25139