--- Log opened Thu May 16 00:00:14 2019
01:29 < gmaxwell> Stuck state: calling free(0LL)
01:29 < gmaxwell> ERROR: Undefined behavior
01:30 < gmaxwell> ^ I think it's full of it, free(NULL) is defined last I checked.
02:48 < real_or_random> if NULL is 0LL, can we conclude that NU is 0?
02:51 < gmaxwell> and 0 times any number is 0   then NUMBERS = NU MUBERS = NU = 0 so all numbers are zero.
03:02 < real_or_random> I knew it
05:55 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-adivsgnowajdyxpd] has joined #secp256k1
08:12 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]
08:12 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #secp256k1
11:20 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-adivsgnowajdyxpd] has quit [Quit: Connection closed for inactivity]
11:22 -!- afk11 [~afk11@unaffiliated/afk11] has joined #secp256k1
13:27 < gmaxwell> sipa: naughty naughty VERIFY_CHECK((r + len <= a) || (a + len <= r));
13:42 < gmaxwell> roconnor: Language lawyer question, is there _any_ way in the language to check if two objects overlap without creating UB?  I am thinking that any pointer comparison between different objects is undefined.
13:44 < real_or_random> reminds me of https://github.com/bitcoin-core/secp256k1/pull/578/commits/5f04e82bc103b3c011c98e2860430ae87bfc83ea#diff-f97778dfdab158cddb48a831ecd8a395
13:44 < gmaxwell> (and, while on the implemenetations, machines we use, these sorts of comparisions are safe, they're not the most portable.. e.g. due to segmented memory, different objects could be in different segments seperated by type, and could falsely compare as equal when they don't in fact overlap)
13:45 < real_or_random> roconnor: yes I think you just cannot do this. it's your job to keep track of your pointers upfront
13:46 < gmaxwell> real_or_random: right, but in this case, I don't actually see how to fix it in a language lawyer safe way because they're different objects.  I'm confident that what its doing is fine in GCC/Clang, but I'd prefer to use wonk-safe behavior (if nothing else so I don't have to restart ccomp inerp after its run for two hours... :P )
13:46 < real_or_random> I had a similar issue in the "preallocated" PR... there is no way to check if some pointer is aligned
13:47 < gmaxwell> There is a C99 align function, no? you could align and check equality?
13:47 < real_or_random> there's alignof for types in C11 (?) but I don't know an align function
13:47 < roconnor> gmaxwell: I'm not aware of any way to do it.
13:48 < gmaxwell> ah alignof is what I was thinking.
13:48 < real_or_random> and you can emulate alignof with a super ugly ifdef that probably works in practice
13:48 < gmaxwell> okay, well I can move that VERIFY_CHECK and any similar one behind an ifdef.
13:49 < real_or_random> what you can do is cast to an integer and divide it by the alignment. but that's implementation-defined (well at least not UB)
13:49 < real_or_random> #define alignof(type) ((size_t)&((struct { char c; type d; } *)0)->d)
13:49 < gmaxwell> I wish that GCC/clang would maintain a clear single location list of formally UB that they implementation define.
13:50 < gmaxwell> real_or_random: casting to an integer and masking is cleaner and the same thing wrt implementation defined.
13:51 < roconnor> real_or_random: I doubt that is defined behaviour and a null pointer isn't even 0 on all systems.
13:51 < roconnor> (I doubt it is not undefined behaviour)
13:52 < real_or_random> roconnor: the #define? should be implementation-defined
13:52 < real_or_random> because it's casting between pointers and integers
13:53 < real_or_random> (no matter if 0 is NULL or not)
13:53 < roconnor> I double the -> operater is not undefined for those inputs.
13:53 < roconnor> *doubt
13:53 < gmaxwell> You can always use '0' as a way of typing a null pointer, regardless of its representation.  but if null is not 0 you're gonna get some crazy result there. also that appears to be computing the address of a non-existing object...
13:53 < real_or_random> but it's almost as ugly as #define STATIC_ASSERT(COND,MSG) static int static_assertion_##MSG[(COND)?1:-1]
13:54 < real_or_random> roconnor: well yeah. don't know. where not actually executing the "->" :) but yes, it could well be true that I'm overlooking sth
13:54 < real_or_random> or that the plain english in the standard is just not precise enough to answer that question
13:56 < roconnor> Hmm, there are some exceptional semantics for &
13:56 < gmaxwell> I mean, no one seems to be able to answer if you can use unions for type conversions or not, violating the aliasing rules. The compiler authors give inconsistent answers if the language allows it (but the compilers do allow it).
13:56 < roconnor> but none the less a 0 pointer isn't guarenteed to be at 0 address
13:56 < gmaxwell> yes but thats implementation defined.
13:56 < roconnor> oh right
13:57 < roconnor> Ya I refuse to do type punning.
13:57 < real_or_random> :D
13:57 < real_or_random> gmaxwell: are you aware of https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/C-Implementation.html ? it's pretty long (but yes, maybe not complete)
13:57 < gmaxwell> (I've also actually used systems where NULL isn't 0)
13:58 < gmaxwell> real_or_random: yes, I'm aware of it. It's unfortunately not at all complete or rather, wasn't last I checked, perhaps it deserves a re-review.
14:04 < roconnor> So the special semantics of & is that &*(foo) is canceled and similarly for &(foo[i])
14:04 < roconnor> but I don't really see anything about ->
14:07 < real_or_random> "foo->bar" is just sugar for (*foo).bar
14:09 < roconnor> That's what I figure
16:40 < gmaxwell> roconnor: FWIW, it takes about 60 GB ram to get through a setup of SECP256K1_CONTEXT_SIGN | SECP256K1_CONTEXT_VERIFY ... variable window G will make the codebase a lot more testable with interp mode.
16:40 < gmaxwell> er real_or_random
16:40 < gmaxwell> sorry, too many r folks in here.
16:44 < gmaxwell> If we do a major refactoring of the tests at some point, we should make it so that its easy to just run one test group at a time (ideally with the RNG structured so that we can run just one test group with the same seed as we got from a all-groups run; e.g. seed each group with a group name + the starup seed or similar)
22:07 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]
22:11 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #secp256k1
--- Log closed Fri May 17 00:00:15 2019