Path: utzoo!attcan!uunet!jarthur!usc!elroy.jpl.nasa.gov!ucla-cs!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.wizards
Subject: Re: what are st_blksize and st_blocks exactly?
Message-ID: <13368@smoke.BRL.MIL>
Date: 17 Jul 90 14:19:32 GMT
References: <138932@sun.Eng.Sun.COM> <38770@sequent.UUCP> <3671@auspex.auspex.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 21

In article <3671@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>Watch out for this "usually 8K" assumption; it has caused no end of grief.
>Yes, and I think Pyramid may support a 16K block size; this causes
>programs such as one version of "ex", which assumed you'll *never* have a
>block size bigger than 8K, no end of grief.

I think the X-MP UniCOS sets BUFSIZ to 64K.
Indeed, this triggered unexpected behavior in one of our application
that was prepared to cope with any reasonable BUFSIZ, but for
testing purposes the applications buffers, which were scaled according
to BUFSIZ, were assumed to be small enough that the test case would
cause buffer overflow, which it didn't on the X-MP, thereby failing
the test (even though the code was correct, the test depended on
buffer overflow occurring).
It is useful for the programmer to identify all such environmental
assumptions and code tests for them, e.g.
	#if BUFSIZ > 8192
	#include "*** ERROR: code depends on BUFSIZ <= 8192 ***"
	#endif
or
	assert(BUFSIZ <= 8192);