Michael Haggerty <mhag...@alum.mit.edu> writes: > On 03/06/2015 06:08 AM, Torsten Bögershausen wrote: >> On 03/05/2015 05:07 PM, Michael Haggerty wrote: >>> One likely reason for fdopen() to fail is the lack of memory for >>> allocating a FILE structure. When that happens, try freeing some >>> memory and calling fdopen() again in the hope that it will work the >>> second time. >>> >>> This change was suggested by Jonathan Nieder [1] >>> >>> In the first patch it is unsatisfying that try_to_free_routine() is >>> called with a magic number (1000) rather than sizeof(FILE). But the C >>> standard doesn't guarantee that FILE is a complete type, so I can't >>> think of a better approach. Suggestions, anybody? >> >> it's not the sizeof(FILE) which is critical, it is the size of the buffer >> associated with a FILE >> >> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdio.h.html >> >> BUFSIZ may be your friend, and if it is not defined, 4096 may be a >> useful default. > > Good point. If this patch series is not dropped as being useless, I will > make this change.
OK, it has been a week since anybody mentioned this series. What's the verdict? Taking what you said in $gmane/265228 into account, I am taking the lack of reroll or follow-up as a sign of lost interest, and if that is the case I'd drop the series before it hits 'next'. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
