From @tobez

I don't know whether this failure is expected on non-glibc non-Linux
system... All other tests are successful, though.

pragma/warning......PROG​:
# pp_hot.c
use warning 'io' ;
print STDIN "anc";
print <STDOUT>;
print <STDERR>;
open(FOO, ">&STDOUT") and print <FOO>;
print getc(STDERR);
print getc(FOO);
read(FOO,$_,1);
no warning 'io' ;
print STDIN "anc";
###############################################################
# N O T E #
# This test is known to fail on Linux systems with glibc. #
# The glibc development team is aware of the problem, and has #
# determined a fix for the next release of that library. #
###############################################################
EXPECTED​:
Filehandle main​::STDIN opened only for input at - line 3.
Filehandle main​::STDOUT opened only for output at - line 4.
Filehandle main​::STDERR opened only for output at - line 5.
Filehandle main​::FOO opened only for output at - line 6.
Filehandle main​::STDERR opened only for output at - line 7.
Filehandle main​::FOO opened only for output at - line 8.
Filehandle main​::FOO opened only for output at - line 9.
GOT​:
Filehandle main​::STDIN opened only for input at - line 3.
Filehandle main​::STDOUT opened only for output at - line 4.
Filehandle main​::STDERR opened only for output at - line 5.
Filehandle main​::FOO opened only for output at - line 6.
Filehandle main​::STDERR opened only for output at - line 7.
Filehandle main​::FOO opened only for output at - line 8.
FAILED at test 190

Site configuration information for perl 5.00558:

Configured by tobez at Tue Jul 27 15:09:24 CEST 1999.

Summary of my perl5 (revision 5.0 version 5 subversion 58) configuration:
  Platform:
    osname=freebsd, osvers=3.2-stable, archname=i386-freebsd
    uname='freebsd moose.plab.ku.dk 3.2-stable freebsd 3.2-stable #43: tue jun 1 19:54:02 cest 1999 root@moose.plab.ku.dk:usrsrcsyscompilemoose i386 '
    config_args='-des'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
    use64bits=undef usemultiplicity=undef
  Compiler:
    cc='cc', optimize='-O', gccversion=2.7.2.1
    cppflags='-I/usr/local/include'
    ccflags ='-I/usr/local/include'
    stdchar='char', d_stdstdio=undef, usevfork=true
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags ='-Wl,-E  -L/usr/local/lib'
    libpth=/usr/lib /usr/local/lib
    libs=-lm -lc -lcrypt
    libc=/usr/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-DPIC -fpic', lddlflags='-shared  -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.00558:
    lib
    /usr/local/lib/perl5/5.00558/i386-freebsd
    /usr/local/lib/perl5/5.00558
    /usr/local/lib/site_perl/5.00558/i386-freebsd
    /usr/local/lib/site_perl
    .


Environment for perl 5.00558:
    HOME=/home/tobez
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/usr/local/site/bin:/home/tobez/bin:/home/tobez/bin/kuim:/plab/usr/home/tobez/bin:/plab/usr/local/site/bin
    PERL_BADLANG (unset)
    SHELL=/usr/local/bin/zsh

From @tobez

On Tue, Jul 27, 1999 at 10​:25​:10AM -0700, Gurusamy Sarathy wrote​:

On Tue, 27 Jul 1999 18​:56​:16 +0200, Anton Berezin wrote​:

I don't know whether this failure is expected on non-glibc non-Linux
system... All other tests are successful, though.

FreeBSD seems to have the same affliction as Linux then. I've
attached some traffic with the glibc developers that might help take
it up with the FreeBSD crowd.

Thanks, I'll communicate this with the rest of the FreeBSD crowd. :-)

Message-Id​: <199907210241.TAA27866@​activestate.com>
From​: Gurusamy Sarathy <gsar@​ActiveState.com>

The following little program​:
prints​:

0 ferror=0 feof=0

FWIW, ferror() returns non-zero in the above on all other platforms
I've tried.

Well, you already know that it returns zero on FreeBSD 2.2.8, 3.0, 3.1
and 3.2. A report for 4.0 will follow shortly. I've also found the
same behavior on

  OSF1 biobase.dk V4.0 564 alpha

using cc

  DEC C V5.2-040 on Digital UNIX V4.0 (Rev. 564).

I think you might consider retracting the test as a worthwhile option.
:-)

Cheers,
--
Anton Berezin <tobez@​plab.ku.dk>
The Protein Laboratory, University of Copenhagen

From @gsar

On Tue, 27 Jul 1999 18​:56​:16 +0200, Anton Berezin wrote​:

I don't know whether this failure is expected on non-glibc non-Linux
system... All other tests are successful, though.

FreeBSD seems to have the same affliction as Linux then. I've
attached some traffic with the glibc developers that might help
take it up with the FreeBSD crowd.

Sarathy
gsar@​activestate.com

Message-Id​: <199907210241.TAA27866@​activestate.com>
Date​: Tue, 20 Jul 1999 19​:41​:05 PDT
From​: Gurusamy Sarathy <gsar@​ActiveState.com>
To​: bug-glibc@​gnu.org
cc​: gsar@​activestate.com
Subject​: ferror() after fread() on a FILE* opened for write

The following little program​:

  #include <stdio.h>
  int
  main(int argc, char **argv)
  {
  char buf;
  int r = fread(&buf,1,1,stdout);
  printf("%d ferror=%d feof=%d\n", r, ferror(stdout), feof(stdout));
  return 0;
  }

prints​:

  0 ferror=0 feof=0

The result is unchanged if I replace stdout with the result of, say,
fopen("/tmp/foo","w").

On a stock Debian 2.1 system with libc-2.0.7.so, this causes one of the
tests in the upcoming Perl development release to fail. I'm inclined to
think it is a glibc bug.

FWIW, ferror() returns non-zero in the above on all other platforms
I've tried.

Sarathy
gsar@​activestate.com

Message-Id​: <u87lnumrqp.fsf@​arthur.rhein-neckar.de>
Date​: 21 Jul 1999 08​:39​:10 +0200

From​: Andreas Jaeger <aj@​arthur.rhein-neckar.de>
To​: libc-alpha Mailinglist <libc-alpha@​sourceware.cygnus.com>
cc​: gsar@​activestate.com

Subject​: [Gurusamy Sarathy <gsar@​activestate.com>] ferror() after fread() on a FILE* open
  ***ed for write

--=-=-=

Looking at the appended bug report, I guess we should check for
if (fp->_flags & _IO_NO_WRITES)

in the fread implementation. But what's the right place and who
exactly should we change it?

Could somebody also verify that the reverse situation (writing to a
file that is read only) is handled correctly?

Btw. I checked this with glibc 2.1.2pre1.

Thanks,
Andreas

--=-=-=
Content-Type​: message/rfc822
Content-Disposition​: inline

Date​: Wed Jul 21 08​:32​:16 1999
From​: Gurusamy Sarathy <gsar@​activestate.com>
Subject​: ferror() after fread() on a FILE* opened for write

Topics​:
  ferror() after fread() on a FILE* opened for write

Date​: Tue, 20 Jul 1999 19​:41​:05 -0700
From​: Gurusamy Sarathy <gsar@​activestate.com>
To​: bug-glibc@​gnu.org
cc​: gsar@​activestate.com
Subject​: ferror() after fread() on a FILE* opened for write
Message-Id​: <199907210241.TAA27866@​activestate.com>

The following little program​:

  #include <stdio.h>
  int
  main(int argc, char **argv)
  {
  char buf;
  int r = fread(&buf,1,1,stdout);
  printf("%d ferror=%d feof=%d\n", r, ferror(stdout), feof(stdout));
  return 0;
  }

prints​:

  0 ferror=0 feof=0

The result is unchanged if I replace stdout with the result of, say,
fopen("/tmp/foo","w").

On a stock Debian 2.1 system with libc-2.0.7.so, this causes one of the
tests in the upcoming Perl development release to fail. I'm inclined to
think it is a glibc bug.

FWIW, ferror() returns non-zero in the above on all other platforms
I've tried.

Sarathy
gsar@​activestate.com

End of forwardBcAUri Digest
***************************

--=-=-=

--
Andreas Jaeger aj@​arthur.rhein-neckar.de jaeger@​informatik.uni-kl.de
  for pgp-key finger ajaeger@​aixd1.rhrk.uni-kl.de

--=-=-=--

Message-Id​: <jepv1ma114.fsf@​hawking.suse.de>
Date​: 21 Jul 1999 09​:56​:55 +0200
From​: Andreas Schwab <schwab@​suse.de>
To​: libc-alpha Mailinglist <libc-alpha@​sourceware.cygnus.com>
cc​: gsar@​activestate.com
Subject​: Re​: [Gurusamy Sarathy <gsar@​activestate.com>] ferror() after fread() on a FILE*
  ***opened for write

Andreas Jaeger <aj@​arthur.rhein-neckar.de> writes​:

|> Looking at the appended bug report, I guess we should check for
|> if (fp->_flags & _IO_NO_WRITES)
|>
|> in the fread implementation. But what's the right place and who
|> exactly should we change it?

I cannot find anything in the standard that requires setting the error
indicator when writing to a read-only stream or reading from a write-only
stream. Currently we only check _IO_NO_{READS,WRITES} in the underflow
and overflow methods, so that getc/putc will fail (but getc doesn't set
the error indicator yet; I'm fixing that). Neither xsgetn nor xsputn do
any explicit checking, so they will fail only if the underlying descriptor
is truely write-only or read-only, resp. (but the standard descriptors are
read/write).

Andreas.

--
Andreas Schwab "And now for something
schwab@​suse.de completely different."
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Message-Id​: <19990721140745.48CCF57BA@​ocean.lucon.org>
Date​: Wed, 21 Jul 1999 07​:07​:45 PDT
From​: hjl@​lucon.org (H.J. Lu)
To​: aj@​arthur.rhein-neckar.de (Andreas Jaeger)
cc​: libc-alpha@​sourceware.cygnus.com (libc-alpha Mailinglist),
  gsar@​activestate.com
Subject​: Re​: [Gurusamy Sarathy <gsar@​activestate.com>] ferror() after fread() on a FILE*
  ***opened for write

--=-=-=

Looking at the appended bug report, I guess we should check for
if (fp->_flags & _IO_NO_WRITES)

in the fread implementation. But what's the right place and who
exactly should we change it?

Could somebody also verify that the reverse situation (writing to a
file that is read only) is handled correctly?

How about this patch? I don't know if we should set the error flag
in other places where errno is set.

H.J.

Wed Jul 21 07​:05​:34 1999 H.J. Lu <hjl@​gnu.org>

  * libio/libio/fileops.c (_IO_new_file_underflow)​: Set the error
  flag if fp is not opened for read.
  * libio/oldfileops.c (_IO_old_file_underflow)​: Likewise.

Index​: libio/fileops.c

RCS file​: /work/cvs/gnu/glibc-2.1/libio/fileops.c,v
retrieving revision 1.10
diff -u -p -r1.10 fileops.c
--- libio/fileops.c 1999/05/01 22​:41​:30 1.10
+++ libio/fileops.c 1999/07/21 13​:59​:56
@​@​ -349,6 +349,7 @​@​ _IO_new_file_underflow (fp)
  if (fp->_flags & _IO_NO_READS)
  {
  __set_errno (EBADF);
+ fp->_flags |= _IO_ERR_SEEN;
  return EOF;
  }
  if (fp->_IO_read_ptr < fp->_IO_read_end)
Index​: libio/oldfileops.c

RCS file​: /work/cvs/gnu/glibc-2.1/libio/oldfileops.c,v
retrieving revision 1.2
diff -u -p -r1.2 oldfileops.c
--- libio/oldfileops.c 1999/05/01 22​:41​:30 1.2
+++ libio/oldfileops.c 1999/07/21 13​:59​:18
@​@​ -313,6 +313,7 @​@​ _IO_old_file_underflow (fp)
  if (fp->_flags & _IO_NO_READS)
  {
  __set_errno (EBADF);
+ fp->_flags |= _IO_ERR_SEEN;
  return EOF;
  }
  if (fp->_IO_read_ptr < fp->_IO_read_end)

Message-Id​: <je673e84m3.fsf@​hawking.suse.de>
Date​: 21 Jul 1999 16​:22​:28 +0200
From​: Andreas Schwab <schwab@​suse.de>
To​: hjl@​lucon.org (H.J. Lu)
cc​: aj@​arthur.rhein-neckar.de (Andreas Jaeger),
  libc-alpha@​sourceware.cygnus.com (libc-alpha Mailinglist),
  gsar@​activestate.com
Subject​: Re​: [Gurusamy Sarathy <gsar@​activestate.com>] ferror() after fread() on a FILE*
  ***opened for write

hjl@​lucon.org (H.J. Lu) writes​:

|> How about this patch?

I have already checked this in for libc-2.2. It doesn't change anything
for fread anyway, only fgetc.

Andreas.

--
Andreas Schwab "And now for something
schwab@​suse.de completely different."
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Message-Id​: <u8r9m23tin.fsf@​arthur.rhein-neckar.de>
Date​: 21 Jul 1999 17​:35​:44 +0200
From​: Andreas Jaeger <aj@​arthur.rhein-neckar.de>
To​: libc-alpha Mailinglist <libc-alpha@​sourceware.cygnus.com>,
  gsar@​activestate.com
Subject​: Re​: [Gurusamy Sarathy <gsar@​activestate.com>] ferror() after fread() on a FILE*
  ***opened for write

Andreas Schwab writes​:

Andreas Jaeger <aj@​arthur.rhein-neckar.de> writes​:
|> Looking at the appended bug report, I guess we should check for
|> if (fp->_flags & _IO_NO_WRITES)
|>
|> in the fread implementation. But what's the right place and who
|> exactly should we change it?

I cannot find anything in the standard that requires setting the error
indicator when writing to a read-only stream or reading from a write-only
stream. Currently we only check _IO_NO_{READS,WRITES} in the underflow
and overflow methods, so that getc/putc will fail (but getc doesn't set
the error indicator yet; I'm fixing that). Neither xsgetn nor xsputn do
Thanks for the fix. Should this go also into glibc 2.1.2?
any explicit checking, so they will fail only if the underlying descriptor
is truely write-only or read-only, resp. (but the standard descriptors are
read/write).

I've modified the program to use fopen​:

#include <stdio.h>
int
main(int argc, char **argv)
{
  char buf[500];
  FILE *f;
  int r;

  f = fopen ("/tmp/foo", "a");
  r = fread(buf, 1, 1, f);
  printf("%d ferror=%d feof=%d\n", r, ferror(f), feof(f));
  return 0;
}

The output of the program is​:
$ ./ferror
0 ferror=0 feof=0

The ISO C9x draft I've got here, mentions as return value for fread​:

  [#3] The fread function returns the number of elements
  successfully read, which may be less than nmemb if a read
  error or end-of-file is encountered. If size or nmemb is
  zero, fread returns zero and the contents of the array and
  the state of the stream remain unchanged.

fread returned 0 which is less than 1 - therefore either a read error
or end-of-file is encountered. But feof and ferror tell me that
neither is encountered.

Is this a valid interpretation of the standard?

Andreas
--
Andreas Jaeger aj@​arthur.rhein-neckar.de jaeger@​informatik.uni-kl.de
  for pgp-key finger ajaeger@​aixd1.rhrk.uni-kl.de

Message-Id​: <jeaesq6jfs.fsf@​hawking.suse.de>
Date​: 21 Jul 1999 18​:45​:11 +0200
From​: Andreas Schwab <schwab@​suse.de>
To​: libc-alpha Mailinglist <libc-alpha@​sourceware.cygnus.com>
cc​: gsar@​activestate.com
Subject​: Re​: [Gurusamy Sarathy <gsar@​activestate.com>] ferror() after fread() on a FILE*
  ***opened for write

Andreas Jaeger <aj@​arthur.rhein-neckar.de> writes​:

|> >>>>> Andreas Schwab writes​:
|>
|> > Andreas Jaeger <aj@​arthur.rhein-neckar.de> writes​:
|> > |> Looking at the appended bug report, I guess we should check for
|> > |> if (fp->_flags & _IO_NO_WRITES)
|> > |>
|> > |> in the fread implementation. But what's the right place and who
|> > |> exactly should we change it?
|>
|> > I cannot find anything in the standard that requires setting the error
|> > indicator when writing to a read-only stream or reading from a write-only
|> > stream. Currently we only check _IO_NO_{READS,WRITES} in the underflow
|> > and overflow methods, so that getc/putc will fail (but getc doesn't set
|> > the error indicator yet; I'm fixing that). Neither xsgetn nor xsputn do
|> Thanks for the fix. Should this go also into glibc 2.1.2?

Yes, I think so. I have checked it in.

|> I've modified the program to use fopen​:
|>
|> #include <stdio.h>
|> int
|> main(int argc, char **argv)
|> {
|> char buf[500];
|> FILE *f;
|> int r;
|>
|> f = fopen ("/tmp/foo", "a");
|> r = fread(buf, 1, 1, f);
|> printf("%d ferror=%d feof=%d\n", r, ferror(f), feof(f));
|> return 0;
|> }
|>
|>
|> The output of the program is​:
|> $ ./ferror
|> 0 ferror=0 feof=0

With my fix this will now return ferror=1.

Andreas.

--
Andreas Schwab "And now for something
schwab@​suse.de completely different."
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg