Tarantool development patches archive
 help / color / mirror / Atom feed
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
To: Nikita Pettik <korablev@tarantool.org>, tarantool-patches@freelists.org
Subject: [tarantool-patches] Re: [PATCH 6/6] sql: allow to specify UNSIGNED column type
Date: Mon, 1 Jul 2019 23:53:02 +0200	[thread overview]
Message-ID: <d00691a3-54a4-a317-48a6-179846332983@tarantool.org> (raw)
In-Reply-To: <f0454db9359200fddb4e39cbbc7d4449cdd5af74.1559919361.git.korablev@tarantool.org>

There still are places, which access Mem.u.i/u without
checking flags properly. Please, for each place either
explain why it is correct, or fix it and add a test.

--------------------------------------------------------------
vdbe.c:2659:
	if ((pDest->flags & (MEM_Int | MEM_UInt)) != 0) {
		if (field_type == FIELD_TYPE_NUMBER)
			sqlVdbeMemSetDouble(pDest, pDest->u.i);
	}

You can't access pDest->u.i - it can be a big unsigned.

--------------------------------------------------------------
vdbe.c:2955:
	pIn1 = &aMem[pOp->p1];
	uint32_t space_id = pIn1->u.i;

Here you touch u.i, but it is always
unsigned. You should use u.u, I think.

--------------------------------------------------------------
vdbeaux.c:2428:
	if (flags & MEM_Int) {

		...

		i64 i = pMem->u.i;
		u64 u;
		if (i < 0) {
			u = ~i;
		} else {
			u = i;
		}

Why do you check 'i < 0', if you already
see its flag is 'Int'. It should be < 0 by
definition.

--------------------------------------------------------------
vdbeaux.c:2589:
		u64 v;
		u32 i;
		if (serial_type == 7) {
			assert(sizeof(v) == sizeof(pMem->u.r));
			memcpy(&v, &pMem->u.r, sizeof(v));
			swapMixedEndianFloat(v);
		} else {
			v = pMem->u.i;
		}

Why are you sure it is safe to store u.i into
uint64_t variable?

--------------------------------------------------------------
vdbeaux.c:2644:
	u64 x = FOUR_BYTE_UINT(buf);
	u32 y = FOUR_BYTE_UINT(buf + 4);
	x = (x << 32) + y;
	if (serial_type == 6) {
		/* EVIDENCE-OF: R-29851-52272 Value is a big-endian 64-bit
		 * twos-complement integer.
		 */
		pMem->u.i = *(i64 *) & x;
		pMem->flags = MEM_Int;

Vice versa - why is it safe to store uint64_t into u.i,
and set its flag to 'Int' (== value is negative).

Actually, all this 'serial' shit looks broken. Please,
verify that code.

--------------------------------------------------------------
vdbeaux.c:2998:
		if ((f1 & MEM_UInt) != 0) {
			if ((f2 & MEM_Real) != 0) {
				return sqlIntFloatCompare(pMem1->u.i,

pMem1 is unsigned, according to the first check,
but you use u.i. Why?

--------------------------------------------------------------
vdbeaux.c:3184:
 do_int:
			if ((pKey2->flags & (MEM_Int | MEM_UInt)) != 0) {
				if (mem1.u.i < pKey2->u.i) {
					rc = -1;

pKey2 is an integer, but you don't know the sign. And use u.i,
assuming it is negative, or at least small enough. Why?

Line 3207 is the same.

--------------------------------------------------------------
vdbemem.c:1431:
			} else if (pVal->u.i == SMALLEST_INT64) {
				pVal->u.r = -(double)SMALLEST_INT64;
				MemSetTypeFlag(pVal, MEM_Real);
			} else {
				pVal->u.i = -pVal->u.i;
			}

You compare u.i and SMALLEST_INT64, but you can't
be sure, that u.i is not a big unsigned, can you?

--------------------------------------------------------------
I will verify u.u, MEM_Int, and MEM_UInt usages, when we
finish with u.i.

  reply	other threads:[~2019-07-01 21:52 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-07 15:37 [tarantool-patches] [PATCH 0/6] Introduce UNSIGNED type in SQL Nikita Pettik
2019-06-07 15:37 ` [tarantool-patches] [PATCH 1/6] sql: refactor sql_atoi64() Nikita Pettik
2019-06-11 21:11   ` [tarantool-patches] " Vladislav Shpilevoy
2019-07-01 14:20     ` n.pettik
2019-07-01 21:53       ` Vladislav Shpilevoy
2019-07-05 16:32         ` n.pettik
2019-06-07 15:37 ` [tarantool-patches] [PATCH 2/6] sql: separate VDBE memory holding positive and negative ints Nikita Pettik
2019-06-11 21:11   ` [tarantool-patches] " Vladislav Shpilevoy
2019-07-01 14:21     ` n.pettik
2019-07-01 21:53       ` Vladislav Shpilevoy
2019-07-05 16:33         ` n.pettik
2019-06-07 15:37 ` [tarantool-patches] [PATCH 3/6] sql: refactor arithmetic operations to support unsigned ints Nikita Pettik
2019-06-11 21:11   ` [tarantool-patches] " Vladislav Shpilevoy
2019-07-01 14:21     ` n.pettik
2019-07-01 21:53       ` Vladislav Shpilevoy
2019-07-05 16:36         ` n.pettik
2019-07-10 22:49           ` Vladislav Shpilevoy
2019-07-17 12:24             ` n.pettik
2019-06-07 15:37 ` [tarantool-patches] [PATCH 4/6] sql: make built-in functions operate on unsigned values Nikita Pettik
2019-06-11 21:11   ` [tarantool-patches] " Vladislav Shpilevoy
2019-07-01 14:21     ` n.pettik
2019-07-01 21:53       ` Vladislav Shpilevoy
2019-07-05 16:36         ` n.pettik
2019-07-10 22:49           ` Vladislav Shpilevoy
2019-07-17  0:53             ` n.pettik
2019-06-07 15:37 ` [tarantool-patches] [PATCH 5/6] sql: introduce extended range for INTEGER type Nikita Pettik
2019-06-11 21:11   ` [tarantool-patches] " Vladislav Shpilevoy
2019-07-01 14:21     ` n.pettik
2019-07-01 21:53       ` Vladislav Shpilevoy
2019-07-24 15:59   ` Konstantin Osipov
2019-07-24 16:54     ` n.pettik
2019-07-24 17:09       ` Konstantin Osipov
2019-06-07 15:37 ` [tarantool-patches] [PATCH 6/6] sql: allow to specify UNSIGNED column type Nikita Pettik
2019-07-01 21:53   ` Vladislav Shpilevoy [this message]
2019-07-05 16:36     ` [tarantool-patches] " n.pettik
2019-07-10 22:49       ` Vladislav Shpilevoy
2019-07-11 21:25         ` Vladislav Shpilevoy
2019-07-17  0:53           ` n.pettik
2019-07-18 20:18             ` Vladislav Shpilevoy
2019-07-18 20:56               ` n.pettik
2019-07-18 21:08                 ` Vladislav Shpilevoy
2019-07-18 21:13                   ` Vladislav Shpilevoy
2019-07-22 10:20                     ` n.pettik
2019-07-22 19:17                       ` Vladislav Shpilevoy
2019-07-22 10:20                   ` n.pettik
2019-07-17  0:54         ` n.pettik
2019-07-18 20:18           ` Vladislav Shpilevoy
2019-08-06 19:36         ` n.pettik
2019-07-24 13:01 ` [tarantool-patches] Re: [PATCH 0/6] Introduce UNSIGNED type in SQL 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=d00691a3-54a4-a317-48a6-179846332983@tarantool.org \
    --to=v.shpilevoy@tarantool.org \
    --cc=korablev@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --subject='[tarantool-patches] Re: [PATCH 6/6] sql: allow to specify UNSIGNED column type' \
    /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