[Top][All Lists]

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

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

From: Georg-Johann Lay
Subject: Re: [avr-libc-dev] fflush() implementation
Date: Sat, 25 Aug 2012 01:07:48 +0200
User-agent: Thunderbird (Windows/20100228)

Weddington, Eric schrieb:
On Behalf Of Georg-Johann Lay
Daniel Otte schrieb:

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


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.
Well, if it's only about debugging an application by ad-hoc sprinkling
commands over the file, I think portability is no issue.  Changing the
ABI for a transient use case like this is not appropriate, IMO.

By the same token, having a non-functional fflush() in avr-libc that doesn't
do anything, just so it can offer source code compatibility seems a bit silly.
At least the proposed feature actually does something with it.

The fflush interface does not change, but common types like FILE and the
hooks therein would.  It's not only about flush, other things will be
affected too.

I'm not opposed to changing the ABI, provided we do it with intent to offer
good functionality as a trade-off. Of course, I agree that we should do it

You could write your application as usual:

#include <stdio.h>

int main (void)
     return fflush (stdout);

In Projects where you use AVR-Libc, supply a C module fflush.c and
a header fflush.h

fflush.c implements fflush to whatever you deem appropriate.
When linking, you link fflush.o to your application, and when
compiling, you compile with -include fflush.h

fflush.h could look like that:

#ifndef FFLUSH_H
#define FFLUSH_H

#define fflush fflush_be_gone
#include <stdio.h>
#undef fflush

extern int fflush (FILE*);
#endif /* FFLUSH_H */

That's it.
No need to change the tools or the ABI.
No need to change yours or others system headers.
No need to explicitly #include "fflush.h"
It' all hidden behind two command options in your Makefile
or build script.

And if you want to run your code without the fflush you
can simply make fflush void or activate in fflush.h a line like

#define fflush(X) (void)(X)

That's certainly another good way of doing it. :-)

Do we have fflush() as a weak symbol?

fflush is static inline in stdio.h.
If it was extern the define above could not work.

Turning it from static inline to (weak) extern is also an ABI
change.  Suppose a library that uses fflush and which is used
with an older distributon of the tools.  Then the user will
get undefined references against fflush.

I don't know much harm such an ABI change is, but everyone
should be aware that it *is* an ABI change.


reply via email to

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