On Thursday, September 20, 2012 8:29:51 AM UTC-6, David Irvine wrote: > > On Thu, Sep 20, 2012 at 3:24 PM, Joseph Galbraith > <[email protected]<javascript:> > > 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 >
I'm not sure how a deque is much (any?) safer... typically a deque is implemented as a vector of vectors (or so google just told me). That seems like a bunch of added complexity that would make it less safe not more? In fact, the C++ standard recommends vector over deque unless you are doing a lot of insert/removal at the beginning and/or end of the container, which is where deque is a win. I guess something that disabled the vector<bool> specialization might be safer (like vector<MyBoolClass>, where MyBoolClass implemented appropriate inline functions to make it a transparent wrapper around bool... but even that introduces complexity and more code for bugs to occur in. In this particular case, I think we were bitten by the fact that clang/libc++ are extremely new code... Thanks, Joseph -- 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.
