🚀 go-pugleaf

In <DCMF28.2tr@ukpsshp1.serigate.philips.nl> baynes@ukpsshp1.serigate.philips.nl (Stephen Baynes) writes:

>Dan Pop (Dan.Pop@mail.cern.ch) wrote:
>: In <rZQHwACMBh107h@rcp.co.uk> alan@rcp.co.uk (Alan Stokes) writes:
>
>
>: >But fread and fwrite are apparently free to add their own encoding.
>
>: No, they aren't.  From 4.9.3:
>
>:     All input takes place as if characters were read by successive
>:     calls to the fgetc function; all output takes place as if characters
>:     were written by successive calls to the fputc function.
>
>: So, fwrite(ucharptr, 1, 1, fp) is guaranteed to be equivalent to 
>: fputc(*ucharptr, fp).
>
>: If some funny encoding occurs, it happens at a lower level of the
>: implementation and it affects all the stdio functions in the same way.
>
>I think that is debatable. It can be interpreted as you suggest and I would
>expect all reasonable implementations to do so. However one can also be 
>interpreted that fread/fwrite must do all its actual io with fgetc/fputc or
>as-if. It does not say what characters are read or written or even how many.
>For example extra characters could be used to achive some sort of alignment
>or even do error checking.
>All it does mean that you could copy the data written with fwrite using 
>fgetc/fputc and then reread the copy using fread to get the original values 
>but it not say anything about the values you fgetc/fputced except they were 
>valid data for fgetc/fputc. To ensure the sensible interpretation something 
>like the following would have to be stated by the standard:
>
>    Each object being read or written is treated as an array of characters
>of the same size as the object. These characters are read or written with
>fgetc or fputc (or as-if) in order of ascending index. The array of objects
>forming the parameter is read or written in ascending order of index. No
>additional characters are read or written.

I think the current wording guarantees the same thing.  Combine the
above quote with the description of fwrite (4.9.8.2) and see what you get.

    The fwrite function writes, from the array pointed to by ptr , up
    to nmemb members whose size is specified by size , to the stream
    pointed to by stream .  The file position indicator for the stream (if
    defined) is advanced by the number of characters successfully written.

So, fwrite does write only as many characters as required by the programmer
(nmenb * size) or less (if some error occurs) as if they were written by
calling fputc.  If fwrite plays any tricks with the byte order, retrieving
the data with fgetc calls won't be possible, hence the standard would be
violated.

Dan
--
Dan Pop
CERN, CN Division
Email: Dan.Pop@mail.cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland