[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[libmicrohttpd] Re: ITALY - memory pool (2)
From: |
Christian Grothoff |
Subject: |
[libmicrohttpd] Re: ITALY - memory pool (2) |
Date: |
Thu, 16 Sep 2010 02:02:10 +0200 |
User-agent: |
KMail/1.13.5 (Linux/2.6.32-5-686; KDE/4.4.5; i686; ; ) |
On Wednesday 15 September 2010 17:39:41 address@hidden wrote:
> Second step: I have to port the MHD library on a generic embedded platform.
> What I would do is:
>
> - Replace all the POSIX calls in the code with function pointers
>
> - Write an MHD_config (mhd_conf_t *conf) function, where the caller
> passes the address of the actual function
>
> In this way the code can be compiled on any platform/compiler and we leave
> the end user to implement the actual functions.
> In principle, one can replace the TCP/IP stack with a RS232 stack as a
> transport layer.
I think this should be done using macros instead of function pointers.
Function pointers will confuse existing tools (such as static analysis tools)
and make the code harder to read for a feature that most users won't need.
We've used the macro approach to provide a POSIX-like API for W32 systems and
it worked quite well (PlibC). Also, if you use macros, your C compiler will
likely be able to do a better job optimizing your code (especially for your
embedded system).
> That's the way I did it when I ported the FreeDOS FAT 16 filesystem.
>
>
> I see here also another smaller problem: the ordinary Windows user doesn't
> know how to build the code with Cygwin.
> I would add a separate project file for MSVC.
>
> What do you think?
I don't see a problem with having another build file --- however, I won't be
able to maintain it (no MSVC here...). Still, even a slightly outdated build
file might be better than nothing for some users.
Happy hacking,
Christian