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]<javascript:> > > wrote: > >> On Sep 17, 2012, at 5:35 PM, Joseph Galbraith >> <[email protected]<javascript:>> >> 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]<javascript:> >> > >> >> 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 >
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 This is not totally related but if you are using clang with libc++ then you > will find this useful. > > I think if somebody could run the clang static_analysis on cryptopp and > attend to some of the actual positives that it throws up it would be great. > (hint hint !!) > > I agree with Marshal in this case the risk to the algorithm does exist > with the change (risk, not proven) but with static analysis there is many > more obvious issues. > > 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.
