> Date: Thu, 14 May 2009 19:44:50 -0400 > From: Michael Gold <[email protected]> > 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
