--- Day changed Wed Nov 02 2016
09:45 -!- jtimon [~quassel@95.131.169.251] has joined #secp256k1     
10:04 -!- jtimon [~quassel@95.131.169.251] has quit [Ping timeout: 260 seconds]     
11:24 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #secp256k1     
11:43 -!- echonaut5 [~echonaut@46.101.192.134] has joined #secp256k1     
11:43 -!- echonaut [~echonaut@46.101.192.134] has quit [Read error: Connection reset by peer]     
13:16 -!- gwillen [~gwillen@unaffiliated/gwillen] has joined #secp256k1     
13:17 < gwillen> hi all. I appearing to be running into this gcc issue in building/running libsecp256k1 on Arm
13:17 < gwillen> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
13:18 < gwillen> gcc is compiling a *foo=*bar to a memcpy, where foo and bar are pointers to the same struct; the copy (which libsecp does) is allowed, but the memcpy (which gcc compiles it to on arm) is forbidden by the contract of memcpy
13:18 < gwillen> it's not clear (or at least, the gcc devs argue about it on the bug thread) whether this is actually a problem (what memcpy does or does not promise on what architecture, beyond what is required of it)
13:18 < gwillen> but it does make valgrind upset.
13:39 < sipa> why is it forbidden by memcpy?
13:40 < gwillen> sipa: that's just how it's defined in the standards, see e.g. http://pubs.opengroup.org/onlinepubs/009695399/functions/memcpy.html
13:40 < gwillen> "If copying takes place between objects that overlap, the behavior is undefined."
13:40 < nsh> is undef
13:41 < gwillen> (If you mean "why would it be defined this way", it's because obvious implementations can produce nonsense results in this case.)
13:41 < gwillen> (E.g. if you copy bytes forward in order, and dest starts halfway into source, you'll end up destroying the latter half of source before you copy it.)
13:41 < gwillen> (Apparently various people have considered the specific case of dest==source, and it's _harder_ to fuck that up, but the gcc bug thread mentions a way to do it e.g. on PowerPC.)
13:42 < gmaxwell> gwillen: what do you mean by 'running into this gcc issue'?
13:42 < gwillen> gmaxwell: I mean, I build libsecp256k1 on arm, and I run it under valgrind, and valgrind warns that it's making improper use of memcpy
13:43 < gmaxwell> Ignore it. It's just wrong.
13:43 < gmaxwell> Technically the error is in GCC but so long as gcc and glibc are playing nice with each other, life is good.
13:44 < sipa> gwillen: also, screwing up partial overlap is way easier than full overlap (identical pointers)
13:44 < gwillen> I recommend you read the gcc bug thread -- glibc specifically makes no promises about this, and it's an open consideration to ask glibc to make such a promise.
13:44 < gwillen> But in any case, I don't have any interest in pursuing this in detail
13:44 < gwillen> I was told that this channel was the appropriate place to bring it up, and now I have done so
13:44 < gwillen> do with it what you will :-)
13:45 < gmaxwell> gwillen: I'm familar with it. (the reason I asked what you meant by 'running into' is that it's not something that could currently cause problems).
13:46 < gmaxwell> gwillen: the same dispute has gone on for years now with clang, and there they've said they will not change behavior.
13:46 < gmaxwell> gwillen: in any case, it's not a problem in our code.  foo=foo is perfectly well defined C.
13:46 < gwillen> agree
13:47 -!- gwillen [~gwillen@unaffiliated/gwillen] has left #secp256k1 []     
17:21 -!- waxwing [~waxwing@62.205.214.125] has quit [Ping timeout: 256 seconds]     
17:22 -!- waxwing [~waxwing@62.205.214.125] has joined #secp256k1     
17:47 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-aeyyjswbshpotbut] has quit [Quit: Connection closed for inactivity]     
18:53 -!- echonaut5 [~echonaut@46.101.192.134] has quit [Remote host closed the connection]     
18:53 -!- echonaut [~echonaut@46.101.192.134] has joined #secp256k1     
19:42 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 256 seconds]     
21:52 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-salhegiybjoqgylo] has joined #secp256k1