On Nov 4, 12:00 am, Trond Norbye <[email protected]> wrote:
> [...]
> Other "problems" you may encounter is:
>
> * Declarations of variables when they are used, and not in the beginning
> of the scope (this includes inside for () etc)
> * Some places in the code use // for comments
> * uint64_t and the use of PRIu64 in printf's
> * bool as a datatype
> * nameless unions
> * some struct initalizers where we address arrays and members directly..
>
> Do your compiler support that?

* Declarations - not supported(!!!)
* C99 comment style - supported
* uint64_t - supported (even in C mode, I think; for sure in C++ mode,
or this would be a showstopper for me)
* bool - can be faked
* anonymous unions - supported
* offsetof(), etc. - not sure (requires more research)

Of course, the major show-stopper here are the inline declarations.
However, the more interesting question is whether we really need to
compile memcached as C code under VC9.  I'm fairly sure most of these
issues will just go away if we compile as C++ code (that is, create a
VC9 project which tells Visual Studio alone to compile as C++, which
it prefers anyway).  I'm sure some people will howl and holler about
exceptions, vtables, RTTI, multiple-inheritance, and a whole raft of
other completely irrelevant issues, but it seems to me that this will
make the code *just work*.  Of course, I will have to play with it
quite a bit more to justify that claim.  My guess is that VC9 can be
made to shut up about scary uses of struct member access and 0-length
arrays with some strategically placed warning suppression pragmas (for
instance, VC9 is quite happy to both identify 0-length array members
as "non-standard" and to allow their use in C++ mode, while it
considers them totally kosher in C mode).  Is this a viable way
forward?

Note that I am relying on VC9 here and have no interest in VC8's
shortcomings (apologies to anyone who can't afford to upgrade to VC9).

Dave

Reply via email to