🚀 go-pugleaf

In <rZQHwACMBh107h@rcp.co.uk> alan@rcp.co.uk (Alan Stokes) writes:

>In <danpop.807025255@rscernix> Dan.Pop@mail.cern.ch (Dan Pop) writes:
>
>>and fwrite will write a 4-byte quantity as 4 characters in the
>>file.  
>Says who? I don't see anything in the standard that requires this.

The standard requires 4 characters to be written to the stream.  The
standard doesn't say anything, of course, what will happen to those 4
characters on their way to the file associated to the stream.
>
>>fread will read the same 4 characters and store them at the
>>required address.  
>fread must read what fwrite wrote (actually I can't see where the standard
>explicitly guarantees that, but I think it's implied).

Here's the explicit guarantee from ANSI 4.9.2:

    A binary stream is an ordered sequence of characters that can
    transparently record internal data.  Data read in from a binary stream
    shall compare equal to the data that were earlier written out to that
    stream, under the same implementation.
>
>>Neither fwrite nor fread don't know or care about the format of the
>>data or any other details apart from the number of characters which
>>have to be written or read.  Everything else is programmer's
>>responsibility, because s/he's supposed to know what is the
>>meaning/format/encoding/etc of the data manipulated with fread/fwrite.

>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.

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