On Thu, Sep 20, 2012 at 3:24 PM, Joseph Galbraith <[email protected] > wrote:
> > > On Thursday, September 20, 2012 8:18:02 AM UTC-6, David Irvine wrote: >> >> On Thu, Sep 20, 2012 at 2:57 PM, Marshall Clow <[email protected]>wrote: >> >>> On Sep 17, 2012, at 5:35 PM, Joseph Galbraith <[email protected]> >>> wrote: >>> >>> > Building wake.cpp with clang and -std=c++11 -stdlib=libc++ generates >>> errors do narrowing. I believe the following patch is the right way to fix >>> these. Any chance of getting this applied (or something else that makes it >>> build out of the box) ? >>> >>> This patch bothers me. >>> I (think I) understand the problem, and the rationale for the fix. >>> >>> But there's some subversion of the type system going on here, and it >>> might be better to fix that, rather than continue it. >>> >>> To summarize: >>> int arr [] = { >>> 0x12345678, >>> 0x89ABCFEF >>> }; >>> >>> Both of the values in the array are actually unsigned, and have to be >>> (implicitly) converted to int. >>> When compiling for c++11, clang (rightly) complains that 0x89ABCFEF is >>> bigger than the maximum number representable by an int. >>> >>> Changing the type of the array to "unsigned int" (or just unsigned) >>> removes the compile-time error - but does it change the algorithm? >>> >>> >>> -- Marshall >>> >>> Marshall Clow Idio Software <mailto:[email protected]> >>> >>> >>> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is >>> promptly moderated down to (-1, Flamebait). >>> -- Yu Suzuki >>> >> >> >> There is more to the clang/cryptopp compile errors found here -- >> http://sourceforge.net/apps/**trac/cryptopp/ticket/17<http://sourceforge.net/apps/trac/cryptopp/ticket/17> >> >> > > This particular problem is a bug in clang, and is fixed on clang trunk. I > have > worked around it by copying the trunk headers for libc++ over my installed > headers (which works as long as I don't access one particular function out > of <atomic>.) > > Thanks, > > Joseph > >> >> Thanks for that Joseph, although a vector of bools is always a daunting thing to see for many reasons :-) I kinda like the replacement with a deque or similar in this case for safety, although cryptopp does squeeze as much as possible out of every c/c++ type. Cheers David -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com.
