Re: [avr-libc-dev] fflush() implementation

[Daniel Otte]

Hi,
I do not have a copy of a ISO-C standard at hand, but I found a copy of a Draft
of ISO-C 99 [1] dated on August 3, 1998 which says (on page 255):

  If stream points to an output stream or an update stream in which the most
  recent operation was not input, the fflush function causes any unwritten data
  for that stream to be delivered to the host environment to be written to the
  file; otherwise, the behavior is undefined.

I would interpret this in a way which means that fflush has to call a "host
environment function" which serves the purpose of pushing the data further
towards its final destination.

I may add that the debug-sceneraio was just one example and I think it would not
be difficult to come up with others which could use a behavior as I would like
to see from fflush()

( You may consider an eeprom-file-driver which has to be flushed before going
into power down / a modem communication component / some kind of packet based
communication driver which would like to collect data to reduce overhead / ... )

I am not aware of a very strict definition of ABI or ABI change, but since all
functions handling with the internals of __file should be encapsulated within
the library, a change to it would not touch the components of the ABI a user is
expected/recommended to use. There are enough warnings around the __file
definition that user code should not use the internals and that this internals
may change at any time. So I do not really sea a problem here.

A valid point is that a change in the __file structure requires to check if all
functions using this structure work after the change.

[1] http://www.dkuug.dk/JTC1/SC22/WG14/www/docs/n843.pdf

Am 25.08.2012 20:30, schrieb Philipp Schafft:
> reflum,
> 
> On Fri, 2012-08-24 at 21:55 +0200, Daniel Otte wrote:
>> Hi,
>> the current state of fflush() according to stdio.h is:
>>    Flush \c stream.
>>
>>    This is a null operation provided for source-code compatibility
>>    only, as the standard IO implementation currently does not perform
>>    any buffering.
>>
>> This is ok for the stream implementation itself if it is not buffering, but 
>> if
>> the device driver which forms the base of the stream performs buffering it 
>> may
>> be would like to be informed if fflush() is called to flush its own buffers.
> 
> Please note that fflush() doesn't do that on any system. It only flushes
> the buffers within the FILE* object.
> 
> For example from fflush(3) (note the *3* here) of my system:
>         Note  that  fflush()  only  flushes the user space buffers
>         provided by the C library.  To ensure that the data is
>         physically stored on disk the kernel buffers must be flushed
>         too, e.g. with sync(2) or fsync(2).
> 
> If the stdio support (the 'user space' part in the text above) does not
> buffer fflush() should just do nothing.
> 
> Still it could be considered adding a new function similar to fsync() or
> fdatasync() to allow flushing data in the driver.
> 
> Note: I very welcome that the function exists as noop which helps
> porting.
> 
> Wish a nice weekend!
>

signature.asc
Description: OpenPGP digital signature