From: Alexander Turenko <alexander.turenko@tarantool.org> To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Cc: Kirill Shcherbatov <kshcherbatov@tarantool.org>, tarantool-patches@freelists.org Subject: [tarantool-patches] Re: [PATCH v1 1/1] lua: fix strange behaviour of tonumber64 Date: Mon, 16 Jul 2018 16:42:10 +0300 [thread overview] Message-ID: <20180716134210.zp3tckp3gcgchm4q@tkn_work_nb> (raw) In-Reply-To: <ac001997-5bfb-443d-5f21-ac345a29bd7d@tarantool.org> > > > > > 3. Why not 'result > LLONG_MAX'? As I understand, abs(LLONG_MAX) == abs(LLONG_MIN), > > > it is not? (http://www.cplusplus.com/reference/climits/) > > > > > > > No, LLONG_MAX is 2^63-1, but LLONG_MIN is -2^63. We want to compare > > result with 2^63. We are trying to do so in platform-independent way > > (hovewer unsiged unary nimus equivalence with signed one is likely > > two-complement number representation property and can be violated on > > other platforms). > > > > Are you think we should introduce our own constant > > 9223372036854775808ULL (2^63) and avoid that complex assumptions set? It > > Ultimately no. We should not invent the constants. > > > would be explicitly number-representation-dependent, so maybe it is > > better. > > Ok. Logically we want an error on -result < INT64_MIN, right? > It is the same as result > -INT64_MIN. But we can not say > -INT64_MIN because abs(INT64_MIN) > INT64_MAX, yes? > Yes. > Then lets rephrase the comparison: > > result > -INT64_MIN > | > v > result + 1 >= -INT64_MIN > | > v > result >= -INT64_MIN - 1 > | > v > result >= -(INT64_MIN + 1) <- that is the solution. > > As I understand, -(INT64_MIN + 1) is exactly 2^63 - 1 and > fits in int64, right? 2nd step should be result - 1 >= -INT64_MIN, so not it is not the decision. Overflow is unavoidable while we are trying to operate within the signed type. WBR, Alexander Turenko.
next prev parent reply other threads:[~2018-07-16 13:42 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-07-13 11:21 [tarantool-patches] " Kirill Shcherbatov 2018-07-16 10:23 ` [tarantool-patches] " Vladislav Shpilevoy 2018-07-16 12:49 ` Alexander Turenko 2018-07-16 13:15 ` Vladislav Shpilevoy 2018-07-16 13:42 ` Alexander Turenko [this message] 2018-07-16 13:55 ` Vladislav Shpilevoy 2018-07-16 14:09 ` Alexander Turenko 2018-07-16 16:52 ` Kirill Shcherbatov 2018-07-17 9:35 ` Vladislav Shpilevoy 2018-07-17 11:27 ` Alexander Turenko 2018-07-17 12:03 ` Kirill Shcherbatov 2018-07-17 21:48 ` Vladislav Shpilevoy 2018-07-19 10:46 ` Kirill Yukhin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180716134210.zp3tckp3gcgchm4q@tkn_work_nb \ --to=alexander.turenko@tarantool.org \ --cc=kshcherbatov@tarantool.org \ --cc=tarantool-patches@freelists.org \ --cc=v.shpilevoy@tarantool.org \ --subject='[tarantool-patches] Re: [PATCH v1 1/1] lua: fix strange behaviour of tonumber64' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox