From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-348311-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 17549 invoked by alias); 24 Feb 2011 15:04:54 -0000
Received: (qmail 17537 invoked by uid 22791); 24 Feb 2011 15:04:52 -0000
X-SWARE-Spam-Status: No, hits=-2.8 required=5.0	tests=ALL_TRUSTED,AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from localhost (HELO gcc.gnu.org) (127.0.0.1)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 Feb 2011 15:04:49 +0000
From: "jb at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jb at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: jvdelisle at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.6.0
X-Bugzilla-Changed-Fields:
Message-ID: <bug-47694-4-Sk5TX8Mvsu@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-47694-4@http.gcc.gnu.org/bugzilla/>
References: <bug-47694-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Date: Thu, 24 Feb 2011 15:08:00 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2011-02/txt/msg02777.txt.bz2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694

--- Comment #21 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-02-24 15:04:42 UTC ---
(In reply to comment #20)
> Some random thoughts looking at the patch
> (http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170432) - probably not
> helping at all with the regressions:
> 
> I find the following a bit dubious - thought it was also odd before:
> 
> +  base = fbuf_getptr (dtp->u.p.current_unit);
>    if (base == NULL)
>      return NULL;
> 
> The first line is effectively:
>   base = (char*) (u->fbuf->buf + u->fbuf->pos);
> 
> Thus, base is only NULL if "u->fbuf->buf" == NULL *and* u->fbuf->pos == 0. I am
> not sure about the second part, though I think in practice, fbuf_init has
> (hopefully!) always been called and thus it will never be NULL.

I agree, that NULL check can be removed.

> 
> 
> +      if (q == EOF)
> 
> Does this always work? We have in "static inline int fbuf_getc (gfc_unit * u)":
>     return (unsigned char) u->fbuf->buf[u->fbuf->pos++];
> and "q" is "int".
> 
> The issue I see is the following (quote from POSIX's fgetc(3p)):
> "If the integer value returned by fgetc() is stored into a variable of type
> char and then compared against the  integer constant EOF, the comparison may
> never succeed, because sign-extension of a variable of type char on widening to
> integer is implementation-defined."

You're missing the whole picture. The definition of fbuf_getc in fbuf.h is

static inline int
fbuf_getc (gfc_unit * u)
{
  if (u->fbuf->pos < u->fbuf->act)
    return (unsigned char) u->fbuf->buf[u->fbuf->pos++];
  return fbuf_getc_refill (u);
}

That is, the inlined fast path is for the case when there is data available in
the buffer. If there isn't data, it falls back to fbuf_getc_refill, where if
filling the buffer with more data fails EOF is returned, otherwise the next
character cast to unsigned char. 

FWIW, if you dig into the glibc sources, the getc() macro is implemented in a
very similar way.