--- Log opened Sat Jun 26 00:00:49 2021
01:57 -!- belcher_ is now known as belcher
09:00 < real_or_random> in  hex you need the prefix 0x but you don't need the u suffix
09:10 < sipa> unsigned long is at least 32 bits right?
09:10 < sipa> in that case i think the h suffix is unnecessary
09:10 < sipa> u
09:11 < sipa> because c89 will use one of (int, long, unsigned long) as type of decimal constants without suffix
09:14 < sipa> hmm c99 would use one of (int, long, long long); if long long is only 32 bits, that's a problem
09:14 < sipa> even taking that into account, you could choose to only have a u suffix for constants larger than 2**31-1
09:14 < sipa> :D
09:16 < real_or_random> it's kind of strange that they changed that with c99...
09:16 < real_or_random> I guess it's not possible to make the prefix or suffix part of the macro S?
09:17 < sipa> it may be
09:17 < sipa> i think you can, actually
09:17 < real_or_random> ah but you could define S (x)to have 0u+x
09:18 < real_or_random> (not sure what this will do to compilation time ^^)
09:19 < sipa> you can concatenate literls in macro
09:19 < sipa> using ## iirc
09:20 < real_or_random> ah maybr
09:39 < roconnor> I could put UINT32_C into the macro
09:41 < sipa> uh, obviously
09:48 < sipa> UINT32_C isn't in C99, but it isn't hard to create your own, and we could make it hex: #define U32HEX(x) (0x ## x ## l)
09:50 < sipa> since unsigned long is at least 32-bit, that should always work
10:21 < roconnor> I claim UINT32_C is C99
10:24 < sipa> sorry, isn't in C89 i mean
10:27 < roconnor> neither is unit32_t?
10:28 < roconnor> I guess assuming UINT32_C is available when unit32_t is available probably isn't a great assumption...
10:28 < sipa> you're right, it's all kind of fuzzy
10:30 < sipa> we're aiming for "C89 + uint64_t support" as requirement, but it's not that simple of course
10:30 < sipa> but probably most systems that satisfy that will have UINT32_C
12:19 < gmaxwell> hm? uint32_c is much newer, unless my memory is failing me.  I don't think it's a big deal.
13:44 < roconnor> meanwhile regarding C89
13:44 < roconnor> configure.ac:36: warning: The macro `AC_PROG_CC_C89' is obsolete.
13:44 < roconnor> configure.ac:36: You should run autoupdate.
13:44 < roconnor> ./lib/autoconf/c.m4:1652: AC_PROG_CC_C89 is expanded from...
13:44 < roconnor> configure.ac:36: the top level
17:20 -!- belcher_ [~belcher@user/belcher] has joined #secp256k1
17:23 < gmaxwell> roconnor: So IIRC debian will whine if there is any distributed source file without a license header on it. The autogenerated source file doesn't have one.
17:23 < gmaxwell> I dunno if there is some "this is machine generated" header that their tool will accept.
17:24 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 244 seconds]
18:57 < roconnor> oh I see src/ecmult_static_context.h isn't checked in?
18:59 < gmaxwell> Right!
18:59 < roconnor> but we probably want to check in this one.
19:00 < gmaxwell> it's created on demand by the build system, which creates irritation for cross compliation, and generally complicates compiling.
19:00 < gmaxwell> I think we want to switch to checking both in.
19:07 < roconnor> is the ecmult_static_context.h randomized?
19:32 < sipa> no, it's for verification only
19:33 < gmaxwell> sipa: I think he's asking about the signing context.
19:33 < gmaxwell> And, the signing context isn't randomized. It used to be, but we dropped that to make it static.
19:37 < sipa> gmaxwell: actually, no, the table was never randomized
19:38 < sipa> it's the starting point and scalar offset that were (and still are)
19:38 < sipa> the table is blinded using a NUMS point, which it still is currently, but won't be after multicomb
--- Log closed Sun Jun 27 00:00:49 2021