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] libio: Fix open_memstream flush (NULL)


* Adhemerval Zanella:

>> I think we don't want the malloc call for a call to exit, either.
>> Similarly for __stack_chk_fail, but that's something we need to fix
>> there.
>
> I am not following, what exactly should not call malloc here? Since
> the open_memstream is a valid call, it will allocate both the initial
> internal FILE object (libio/memstream.c:77) and initial buffer 
> (libio/memstream.c:84). Are you saying that we should start with an
> empty buffer instead? If it is the for I think we can do it, but it
> would require more intrusive changes I think.

I think we should make sure that writing the null terminator does not
trigger malloc during abort (or __stack_chk_fail).  That would be
quite wrong IMHO.

I wasn't aware that the buffer is pre-allocated.  Then we probably
need a test which is aware of the size of the preallocated buffer.

> So do you prefer to just add a workaround to disable the single-thread
> optimization for open_memstream and fix it on 2.27?  IMHO this fix touches
> only the open_memstream itself, so it should not regress any other libio
> code so I would prefer than carry a workaround for 2.26.

Which fix?  Linking open_memstream into the global list has quite
far-reaching consequences.  Conservatively setting the flag instead
should be fine.

I'm also not sure that the intent of POSIX is that open_memstream
streams should be affected by fflush (NULL).  I expect that
open_memstream was added without considering the interaction with
fflush (NULL).


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