http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694
--- Comment #20 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-24 14:17:40 UTC --- 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. + 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."
