Re: [pdf-devel] Fsys read/write return value.

[gerel]

 > Date: Thu, 14 May 2009 19:44:50 -0400
 > From: Michael Gold <address@hidden>
 > Content-Disposition: inline
 > 
 > 
 > --CE+1k2dSO48ffgeK
 > Content-Type: text/plain; charset=us-ascii
 > Content-Disposition: inline
 > Content-Transfer-Encoding: quoted-printable
 > 
 > On Thu, May 14, 2009 at 02:03:26 -0300, gerel wrote:
 > >=20
 > > Hi,
 > >=20
 > > The return description for fsys file read/write is wrong when using the d=
 > efault
 > > disk implementation, since fread/fwrite return the number of 'elements'
 > > read/written, not the number of octets.
 > > For them to return the number of octets they should be called like:
 > >=20
 > >   fread/fwrite (data, 1, num_elems, file); /* note the '1' there */
 > =2E..
 > 
 > I just noticed this too, and mentioned it in another message.
 > 
 > Is it necessary to support element sizes other than 1?  It may add
 > complexity for filesystem implementations that don't use fread, such as
 > network filesystems (for example, recv only supports bytes, so anything
 > using recv would need to implement some buffering in case the number of
 > bytes returned isn't evenly divisible by num_elems).
 > 
 > Removing num_elems (and always using byte counts) would avoid this type
 > of complexity.
 > 

Hi Michael,

That's _exactly_ why I raised the issue, other implementations would have extra
complexity.  Also, what happens when a byte-oriented stream can't read a whole
ELEM_SIZE element but a smaller one, we can't return and say "a half element was
read".

I suggest getting rid of the ELEM_SIZE+ELEM_COUNT variables.  And, if a bigger
than 1 octet should be read for buffering issues (fread/fwrite), that
should be managed by the implementation and not published by the API.

OTOH, I'd add a pdf_status_t variable either as an output parameter,
or as a return value (and pass a pointer for returning the written/read size).
We need a status flag.


regards,
-gerel