> -----Original Message-----
> From: avr-libc-dev-bounces+eric.weddington=atmel....@nongnu.org [mailto:avr-
> libc-dev-bounces+eric.weddington=atmel....@nongnu.org] On Behalf Of Georg-
> Johann Lay
> Sent: Friday, August 24, 2012 4:19 PM
> To: Daniel Otte
> Cc: AVR-libc-dev@nongnu.org
> 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
_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
