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

[Weddington, Eric]

> -----Original Message-----
> From: address@hidden [mailto:avr-
> address@hidden On Behalf Of Georg-
> Johann Lay
> Sent: Friday, August 24, 2012 4:19 PM
> To: Daniel Otte
> Cc: address@hidden
> Subject: Re: [avr-libc-dev] fflush() implementation
> 
> Daniel Otte schrieb:
> > 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.
> 
> 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.

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

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

Eric