public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
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
Date: Thu, 24 Feb 2011 15:08:00 -0000	[thread overview]
Message-ID: <bug-47694-4-Sk5TX8Mvsu@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-47694-4@http.gcc.gnu.org/bugzilla/>

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.


  parent reply	other threads:[~2011-02-24 15:04 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-11  7:34 [Bug fortran/47694] New: " David.Duffy at qimr dot edu.au
2011-02-11 14:42 ` [Bug fortran/47694] " burnus at gcc dot gnu.org
2011-02-11 20:12 ` jvdelisle at gcc dot gnu.org
2011-02-11 20:40 ` burnus at gcc dot gnu.org
2011-02-11 22:01 ` [Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] " burnus at gcc dot gnu.org
2011-02-14 14:55 ` burnus at gcc dot gnu.org
2011-02-14 15:33 ` burnus at gcc dot gnu.org
2011-02-14 21:32 ` burnus at gcc dot gnu.org
2011-02-14 22:08 ` burnus at gcc dot gnu.org
2011-02-15  1:24 ` jvdelisle at gcc dot gnu.org
2011-02-15  9:14 ` burnus at gcc dot gnu.org
2011-02-15  9:50 ` jb at gcc dot gnu.org
2011-02-17  1:13 ` jvdelisle at gcc dot gnu.org
2011-02-17 12:14 ` jb at gcc dot gnu.org
2011-02-17 13:16 ` jvdelisle at gcc dot gnu.org
2011-02-19  0:23 ` jvdelisle at gcc dot gnu.org
2011-02-22 19:59 ` jb at gcc dot gnu.org
2011-02-23  7:12 ` jb at gcc dot gnu.org
2011-02-23  7:53 ` jb at gcc dot gnu.org
2011-02-24 13:18 ` burnus at gcc dot gnu.org
2011-02-24 14:24 ` burnus at gcc dot gnu.org
2011-02-24 15:08 ` jb at gcc dot gnu.org [this message]
2011-02-24 15:23 ` jb at gcc dot gnu.org
2011-03-04 14:43 ` jvdelisle at gcc dot gnu.org
2011-03-05  0:06 ` jvdelisle at gcc dot gnu.org
2011-03-05  0:21 ` jvdelisle at gcc dot gnu.org
2011-03-05  9:54 ` burnus at gcc dot gnu.org
2011-03-05 15:40 ` jvdelisle at gcc dot gnu.org
2011-03-07  3:09 ` jvdelisle at gcc dot gnu.org
2011-03-07  3:16 ` jvdelisle at gcc dot gnu.org
2011-03-07  3:17 ` jvdelisle at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-47694-4-Sk5TX8Mvsu@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).