Path: utzoo!utgpu!watmath!clyde!mcdchg!chinet!att!osu-cis!tut.cis.ohio-state.edu!ukma!husc6!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.std.c
Subject: Re: What's a good prototype for write(2)?
Message-ID: <8798@smoke.BRL.MIL>
Date: 29 Oct 88 21:41:44 GMT
References: <902@vsi.COM> <6794@pasteur.Berkeley.EDU> <21763@watmath.waterloo.edu> <8777@smoke.BRL.MIL> <21785@watmath.waterloo.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Distribution: comp
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20

In article <21785@watmath.waterloo.edu> rbutterworth@watmath.waterloo.edu (Ray Butterworth) writes:
>One question though.  If the "correct" type is (int) or (unsigned int),
>does that mean that 16-bit-int machines will not be allowed to have
>write() functions that can write more than 16-bits worth of data
>even though the non-C part of the software and hardware is quite
>capable of it?  That seems like a silly restriction.  In particular,
>that makes it impossible to write a C program for a 16-bit C compiler
>that can read a tape written with 128K blocks.  ("sorry, you'll have
>to use fortran; C can't handle that"?)

Presumably such a system could provide an ioctl() or some other special
means of transferring such data, or provide internal buffering etc.

In fact, PDP-11 UNIX could not read or write tape records containing
more than 64K-1 bytes.  Note that ANSI standards for 1/2" magtape
prohibit records more than 2K bytes, and some magtape systems are
unable to handle more than 5K.  Thus inter-system portable interchange
is already constrained well below the size that causes problems for
read()/write(), and on a given system if one cannot write too-long
records then of course there is no problem with reading them back.