This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v3] libio: do not unbuffer legacy standard files in compatibility mode [BZ #24228]


On Wed, Jun 19, 2019 at 03:10:14PM +0200, Florian Weimer wrote:
> * Dmitry V. Levin:
> 
> > diff --git a/libio/genops.c b/libio/genops.c
> > index 2a0d9b81df..aa92d61b6b 100644
> > --- a/libio/genops.c
> > +++ b/libio/genops.c
> > @@ -789,6 +789,10 @@ _IO_unbuffer_all (void)
> >  
> >    for (fp = (FILE *) _IO_list_all; fp; fp = fp->_chain)
> >      {
> > +#if SHLIB_COMPAT (libc, GLIBC_2_0, GLIBC_2_1)
> > +      if (__glibc_unlikely (&_IO_stdin_used == NULL) && _IO_legacy_file (fp))
> > +	continue;
> > +#endif
> >        if (! (fp->_flags & _IO_UNBUFFERED)
> >  	  /* Iff stream is un-orientated, it wasn't used. */
> >  	  && fp->_mode != 0)
> 
> I believe a better fix would be this, in case an old-style file showed
> up for a different reason:
> 
> #if SHLIB_COMPAT (libc, GLIBC_2_0, GLIBC_2_1)
>           bool potentially_wide_stream = _IO_vtable_offset (fp) != 0;
> #else
>           bool potentially_wide_stream = true;
> #endif
> 	  if (potentially_wide_stream && fp->_mode > 0)
> 	    _IO_wsetb (fp, NULL, NULL, 0);
> 
> This is _IO_new_fclose handles this situation.

Yes, this approach seems to work, too:

diff --git a/libio/genops.c b/libio/genops.c
index 2a0d9b81df..575f0e6584 100644
--- a/libio/genops.c
+++ b/libio/genops.c
@@ -789,6 +789,10 @@ _IO_unbuffer_all (void)
 
   for (fp = (FILE *) _IO_list_all; fp; fp = fp->_chain)
     {
+#if SHLIB_COMPAT (libc, GLIBC_2_0, GLIBC_2_1)
+      if (__glibc_unlikely (_IO_vtable_offset (fp) != 0))
+	continue;
+#endif
       if (! (fp->_flags & _IO_UNBUFFERED)
 	  /* Iff stream is un-orientated, it wasn't used. */
 	  && fp->_mode != 0)

> I fear the test is unreliable because it depends on what fp->_mode
> evaluates to (which is not actually present in the struct with old
> files).  But the test is definitely better than nothing.

Sorry, I couldn't think of a more reliable test than that.


-- 
ldv

Attachment: signature.asc
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]