Re: [Monotone-devel] nvm.options

[Timothy Brownawell]

On 07/26/2010 09:14 AM, Thomas Keller wrote:
> I've talked with Thomas Moschny and he asked on ##c++ for a proper
> solution of the problem. The answers were mainly to replace all "custom
> type" specializations with "real types", i.e. basically what I did
> above, so u32, u64, size_t and all the others pick the proper
> specialization based on their underlying type.
>
> Now this might introduce the problem that we forget one or two
> specializations on less common platforms which worked until now, because
> our autoconf machinery picks different expansions for them.

Actually the autoconf stuff (m4/numeric_vocab.m4) seems fairly simple, 
it uses short, int, and either long or long long. We always need 'long' 
(in case of size_t etc), so the only question is whether to specialize 
for 'long long'.

I now have it defining a test macro in case it actually uses 'long long' 
to get s64 since it looks like 'long long' isn't actually in the 
standard... not sure this is exactly right/useful, since 'long long' is 
the only way we try to get a 64-bit type if 'long' is 32 bits.

> For example, for s32, s64, u32 and u64 I have defined in config.h for
> Mac OS X:
>
> int
> long long
> unsigned int
> unsigned long long
>
> and we probably also need (at least for Linux)
>
> long
> unsigned long
>
> (and cross fingers that they don't collide on some platforms)
>
> What about Solaris, Windows (visualc/config.h has hardcoded int /
> unsigned int for s32 / u32) and the BSDs?

Should all be fine, but it will want USING_LONG_LONG defined if you have 
'long long' for the 64-bit types.

--
Timothy

Free public monotone hosting: http://mtn-host.prjek.net