Scott Cheloha <[email protected]> wrote: > On Fri, Nov 19, 2021 at 07:42:18PM -0700, Theo de Raadt wrote: > > +#include <sys/param.h> /* for MAXBSIZE */ > > > > No way, that is non-POSIX namespace. We are going in precisely the opposite > > direction, eliminating this non-portability from the tree. > > > > No biblical scrolls have it written "all programs must use buffer sizes > > decided by a system header file". > > > > If you want 64*1024 in this specific program then just say 64*1024. > > Is there a nicer way to pick a "reasonable" buffer size when we just > want to move as many bytes as possible on a given platform without > hogging the machine?
Pick a number. Use a number. > I thought MAXBSIZE was that constant, because we use it elsewhere, /* * File system parameters and macros. * * The file system is made out of blocks of at most MAXBSIZE units, with * smaller units (fragments) only in the last direct block. MAXBSIZE * primarily determines the size of buffers in the buffer pool. It may be * made larger without any effect on existing file systems; however making * it smaller makes some file systems unmountable. */ #define MAXBSIZE (64 * 1024) It is a kernel #define being abused by userland programmers. > Is it BUFSIZ? #define BUFSIZ 1024 /* size of buffer used by setbuf */ No, that is the default buffer for stdio sizing. Nothing suggests this is suitable for use by programs. > e.g. in cat(1) and wc(1), but if not then what is the right thing? The right buffer size should be chosen for in a specific program. It is a number which is small enough to not hog the system, yet large enough to gain reasonable benefits versus the cost of servicing/faulting memory. Obviously the number chosen will change during the era, unlike MAXBSIZE and BUFSIZ which are going on 30 years old and were chosen by someone sharing a vax 11/780 (or even smaller machine).
