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

[Georg-Johann Lay]

Weddington, Eric schrieb:
> On Behalf Of Georg-Johann Lay
> > 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.

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

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.


Johann