monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] botan 1.7.3


From: Jack Lloyd
Subject: Re: [Monotone-devel] botan 1.7.3
Date: Thu, 13 Mar 2008 14:48:06 -0400
User-agent: Mutt/1.5.11

On Tue, Feb 19, 2008 at 10:05:34AM +0100, Markus Schiltknecht wrote:

> >g++ 3.4.5 complaints about old code that those big integer constants:
> >
> >a.cpp:9: error: integer constant is too large for 'long' type
> >
> >BTW g++ (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)) also fails
> >to compile original code.

Problem: Visual Studio (and I think other Windows compilers) will
accept a bare 64-bit constant, but don't understand a LL/ULL suffix,
and will halt the compile. So the needed thing is something like

#if __GNUG__
  #define LL64(x) x#ULL
#else
  #define LL64(x)
#endif
[...]
LL64(0x0123456789ABCDEF)

Which I do find really quite ugly.

> Depending on what botan developers want, we should either apply this
> patch to botand and propagate to monotone, or if botan developers
> dislike that longish -ull notation, we should compile botan with
> "-Wno-long-long -fpermissive" as well.

My tendency on this is to use -fpermissive and wait out GCC (since
they have to fix this for C++0x, which like C99 says constants that
fit in a long long or unsigned long long are fine).

If it were necessary to include such constants in headers that
application code would see, that would be a different story, but as
this only affects building the library itself, I'd prefer to not
uglyize the code more than necessary for one compiler. (Partially also
because I don't even have any 32-bit systems anymore, except my
Linksys)

(Overall I would prefer if Monotone's in-tree version of Botan was as
close to n.r.b (or n.r.b.s) as possible since it makes my life easier
re patching)

> BTW: grant me write access to net.randombit.botan, and I'll push the
> patch as a monotone revision. I've attached my pubkey as well.

Your key is now in the randombit.net db + write-permissions - please
consider this as write-after-approval access, though.

Have to restart the server to add a key = not ideal :(

-Jack




reply via email to

[Prev in Thread] Current Thread [Next in Thread]