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
_______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev