avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-libc-dev] fflush() implementation


From: Daniel Otte
Subject: [avr-libc-dev] fflush() implementation
Date: 24 Aug 2012 21:55:20 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.24) Gecko/20100411 Thunderbird/2.0.0.24 Mnenhy/0.7.6.666

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.

I currently run into this case because I have an interrupt-driven UART component
which manages its own buffers. And especially during debugging fflush() is very
helpful as messages may get stuck in the buffer before a crash and you are
searching for the problem at the wrong location.
A possible solution would be using a dedicated flush-function provided by the
driver but this is neither elegant nor very portable.

So a possible solution would be to extend the __file struct with a field
containing a pointer to a driver provided flush-function and registering this
function via a dedicated function. This has the two cons, that the structure
would require more space (2 bytes) and that another auxiliary function is 
required.

Another solution would be to change the prototype of the supplied put-function 
from
  int (*put)(char, FILE *)
to
  int (*put)(int, FILE *)
and use a magic value outside the range of char to trigger the flush-function.
This has the big con, that the prototype has to be changed, and existent
conforming code may cause a warning but (if I remember the ABI correctly) would
still continue to work.

There are a lot of other possible solutions and possible modifications of the
above two (like using a dedicated flag to indicate the presence of the auxiliary
field). Feel free to add other good solutions.

If we agree on a method I could write the necessary patch.

Best regards,
  Daniel

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]