🚀 go-pugleaf

In article <8777@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes:
> In article <21763@watmath.waterloo.edu> rbutterworth@watmath.waterloo.edu (Ray Butterworth) writes:
> >    extern ptrdiff_t write(int, const void *, size_t);

> NO!  There is no guarantee that any C data object can be written
> with a single call to write().

Just as there is no guarantee that any data object whose size
will fit into an (int) can be written with a single call to write().

Short of inventing a new type, say (io_size_t), using (size_t) is no
worse than using (int), and in some ways is more appropriate since the
value of that parameter is likely to come from an expression involving
sizeof.

> Don't go changing the interface from what it is to what you think
> it should have been.

I wasn't.  The original request asked for a "good" prototype,
not a "correct" one.  To get the correct definition, one simply
has to look at the existing UNIX standard, man page, library source,
or header file, and hope most of them are the same.

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"?)