On Thu, 2015-05-14 at 07:42 +0000, Poul-Henning Kamp wrote: > -------- > In message <20150514072155.GT37063_at_funkthat.com>, John-Mark Gurney writes: > > >Since you apprently missed my original reply, I said that we shouldn't > >abuse BUFSIZ for this work, and that it should be changed in mdXhl.c... > > Say what ? > > BUFSIZ is used entirely appropriately in MDXFileChunk(): For reading > a file into an algorithm. > > If in stead of open(2), fopen(3) had been used, the exact same thing > would happen, but using malloc space rather than stack space. > > I think we've got differing interpretations of what BUFSIZ is for. IMO, the one correct use of BUFSIZ outside of libc is "if you are going to call setbuf() the buffer you pass must be BUFSIZ bytes long." Over the years, it seems that many people have somehow gotten the impression that the intent was "BUFSIZ is the right/ideal/whatever size to allocate general purpose IO buffers in any program" and I don't believe that was ever the intent, or was ever correct. All such usage is erronious and must inevitably lead to the situation we've got now: it's so widely misused that it can't be changed in the context of its original purpose without pondering what the wider implications of the change might be. At least I'm inclined to ponder it. Apparently nobody else is. People running servers with more GB of ram than grains of sand on the beach won't care about things like 64k buffers used by /bin/sh to read a line of text, and all the world is big servers now, right? -- IanReceived on Thu May 14 2015 - 12:54:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:57 UTC