Re: [avr-libc-dev] Usage of 'FILE *' in base put/get seems doubtful

[Joerg Wunsch]

As Dmitry K. wrote:

> Whether can somebody result a simple example, where the new
> parameter ('FILE *') would be really useful?

I've been thinking about a useful extension of the stdio API off and
on for quite some time before.

When I saw Ted's suggestion to simply pass the respective FILE * down
to the low-level IO function, I immediately realized that this was
*the* universal solution I've been looking for all the time.
Unfortunately, when I wrote the stdio implementation some 3 years ago,
nobody came up with such a clever idea.

If you look at it from an OO point of view, it's just passing down the
self pointer for the object in question.

Sure, Ted could as well have suggested to pass that void *userdata
field from struct __file down to these functions, but passing the
entire struct __file * makes future extension of the API rather
simple, without creating yet another incompatible API change, by
simply extending the interface struct __file exports to the backend
functions.  That's the main merit I see.

>    On the other hand, transfer 'FILE *' in function of more low
> level, than library 'stdio', seems illogical. Whether it is possible
> to execute, for example, 'fclose' inside 'uart_put'?

Of course, not.  You are not supposed to call application-API entries
of stdio from within the backend functions.

> And in general, whether is though one function with parameter 'FILE
> *' which is safe for using in this case?

Of course, an incorrectly written backend function can cause breakage,
but an incorrectly written application would always be at risk...

I didn't really love to export struct __file into the application's
visibility range (I've seen too many abuses on it in the Unix world
before), but it was the only logical way to eventually do so, short of
having to maintain a dummy version in the user-visible <stdio.h>, and
a private one in stdio_private.h.  Making the structure definition
user-visible allows for some inlined implementations of simple
functions, so it will eventually save code size, which I believe is
much more important for us than whether the user could potentially
damage its own FILE structures.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)