[En-Nut-Discussion] unix port & header files

[Matthias Ringwald]

Hello Harald,

thanks a lot for your suggestion.

that wrapper header file changing all function names
is a very good idea.


On 04.03.2004, at 11:04, Harald Kipp wrote:

> Hi Matthias,
>
> At 09:30 04.03.2004 +0100, you wrote:
>
>> how should the compile distinguish between the nut/os version
>> of fopen and the native fopen call.
>
> Mmh...Deep Thought would say "Tricky".
>
> One idea: Try a stdio wrapper.
>
> 1. All Nut/OS modules will use an include file, which defines
> #define fopen(blah) PREFIX_fopen(blah)
> #define fprint(blah) PREFIX_fprint(blah)
> and so on, plus
> #define FILE PREFIX_FILE

that's quite cool, especially as I don't need to change nut/stdio.h 
(very much)

>
> 2. All application code will use an include file, which defines
>
> #define fopen(blah) WRAPPED_fopen(blah)
> #define fprint(blah) WRAPPED_fprint(blah)
> and so on, plus
> #define FILE WRAPPED_FILE
>
> and
>
> typedef struct {
>   PREFIX_FILE *emul;
>   FILE *native;
> } WRAPPED_FILE;
>

..

> 3. The wrapper module will not use any of those defines and
> thus use the native calls, but implement the wrapped ones.
>
> WRAPPED_FILE *WRAPPED_fopen(char *name, etc)
> {
> ...
> }

Here I thought for a while, if this is really necessary.
(I wanted to implement pseudo uart drivers etc.. that just wrap to 
native stdio )
But I feel something like this is needed.

Besides, it provides a very flexible way of dealing with a mixed sort
of devics.


> The wrapper module must, of course, know all wrapped and prefixed
> prototypes and data types. Use #define and #undef.
>
> I may have overlooked something, but generally it should work.
>
> Another option may be to rewrite the Nut/OS stdio. But
> the advantage with the procedure above is, that you can
> take over any new Nut/OS version without modification.
Agree. That makes the whole thing a lot more feasible
and improves maintainability by orders of magnitude-

>
> Your application code and the Nut/OS bluetooth extensions
> will not notice the wrapping and look like normal, portable
> C programming, at least on Linux. The drag with Winsock is,
> that it doesn't support stdio on sockets.

If that's the only remaining problem, we're done.
If someone is using windows, he already should have cygwin installed
and then everythings fine. if not, he has to => problem solved.. :)

Bye,
  Matthias