Lars Schneider <larsxschneider@xxxxxxxxx> writes: > I think sending it upfront is nice for buffer allocations of big files > and it doesn't cost us anything to do it. While I do NOT think "total size upfront" MUST BE avoided at all costs, I do not think the above statement to justify it makes ANY sense. Big files are by definition something you cannot afford to hold its entirety in core, so you do not want to be told that you'd be fed 40GB and ask xmalloc to allocate that much. It allows the reader to be lazy for buffer allocations as long as you know the file fits in-core, at the cost of forcing the writer to somehow come up with the total number of bytes even before sending a single byte (in other words, if the writer cannot produce and hold the data in-core, it may even have to spool the data in a temporary file only to count, and then play it back after showing the total size). It is good that you allow both mode of operations and the size of the data can either be given upfront (which allows a single fixed allocation upfront without realloc, as long as the data fits in core), or be left "(atend)". I just don't want to see it oversold as a "feature" that the size has to come before data. That is a limitation, not a feature. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html