From: "n.pettik" <korablev@tarantool.org>
To: tarantool-patches@freelists.org
Cc: Kirill Yukhin <kyukhin@tarantool.org>
Subject: [tarantool-patches] Re: [PATCH] sql: do not allow oversized integer literals
Date: Wed, 18 Jul 2018 20:56:47 +0300 [thread overview]
Message-ID: <19FED891-E36F-4D49-84BF-EFE30048CD46@tarantool.org> (raw)
In-Reply-To: <20180718075714.4dl3hlfuuoqimv5p@tarantool.org>
[-- Attachment #1: Type: text/plain, Size: 4358 bytes --]
Except for two minor code-style remarks patch LGTM.
> I think, that this minor change affects visible behaviour. So, let's keep
> tests for such changes in separate files.
As you wish. But I still stick to the point that separate file is ‘over-kill'.
> @@ -3259,51 +3258,48 @@ codeReal(Vdbe * v, const char *z, int negateFlag, int iMem)
> }
> #endif
>
> -/*
> +/**
> * Generate an instruction that will put the integer describe by
> * text z[0..n-1] into register iMem.
> *
> - * Expr.u.zToken is always UTF8 and zero-terminated.
> + * @param parse Parsing context.
> + * @param expr Expression being parsed. Expr.u.zToken is always
> + * UTF8 and zero-terminated.
> + * @param neg_flag True if value is negative.
> + * @param mem Register to store parsed integer
> */
> static void
> -codeInteger(Parse * pParse, Expr * pExpr, int negFlag, int iMem)
> +expr_code_int(struct Parse *parse, struct Expr *expr, bool is_neg,
> + int mem)
> {
> - Vdbe *v = pParse->pVdbe;
> - if (pExpr->flags & EP_IntValue) {
> - int i = pExpr->u.iValue;
> + struct Vdbe *v = parse->pVdbe;
> + if (expr->flags & EP_IntValue) {
> + int i = expr->u.iValue;
> assert(i >= 0);
> - if (negFlag)
> + if (is_neg)
> i = -i;
> - sqlite3VdbeAddOp2(v, OP_Integer, i, iMem);
> + sqlite3VdbeAddOp2(v, OP_Integer, i, mem);
> } else {
> - int c;
> - i64 value;
> - const char *z = pExpr->u.zToken;
> - assert(z != 0);
> - c = sqlite3DecOrHexToI64(z, &value);
> - if (c == 1 || (c == 2 && !negFlag)
> - || (negFlag && value == SMALLEST_INT64)) {
> -#ifdef SQLITE_OMIT_FLOATING_POINT
> - sqlite3ErrorMsg(pParse, "oversized integer: %s%s",
> - negFlag ? "-" : "", z);
> -#else
> -#ifndef SQLITE_OMIT_HEX_INTEGER
> + int64_t value;
> + const char *z = expr->u.zToken;
> + assert(z != NULL);
> + int c = sql_dec_or_hex_to_i64(z, &value);
> + if (c == 1 || (c == 2 && !is_neg)
> + || (is_neg && value == SMALLEST_INT64)) {
Put binary operator to line above:
if (A &&
B…
> diff --git a/src/box/sql/sqliteInt.h b/src/box/sql/sqliteInt.h
> index 18bf949..4a972a1 100644
> --- a/src/box/sql/sqliteInt.h
> +++ b/src/box/sql/sqliteInt.h
> @@ -4354,8 +4354,53 @@ char
> sqlite3TableColumnAffinity(struct space_def *def, int idx);
>
> char sqlite3ExprAffinity(Expr * pExpr);
> -int sqlite3Atoi64(const char *, i64 *, int);
> -int sqlite3DecOrHexToI64(const char *, i64 *);
> +
> +
> +/**
> + * Convert z to a 64-bit signed integer. z must be decimal. This
> + * routine does *not* accept hexadecimal notation.
> + *
> + * If the z value is representable as a 64-bit twos-complement
> + * integer, then write that value into *val and return 0.
> + *
> + * If z is exactly 9223372036854775808, return 2. This special
> + * case is broken out because while 9223372036854775808 cannot be a
> + * signed 64-bit integer, its negative -9223372036854775808 can be.
> + *
> + * If z is too big for a 64-bit integer and is not
> + * 9223372036854775808 or if z contains any non-numeric text,
> + * then return 1.
> + *
> + * length is the number of bytes in the string (bytes, not characters).
> + * The string is not necessarily zero-terminated. The encoding is
> + * given by enc.
> + *
> + * @param z String being parsed.
> + * @param[out] val Output integer value.
> + * @param length String length in bytes.
> + * @retval
> + * 0 Successful transformation. Fits in a 64-bit signed integer.
> + * 1 Integer too large for a 64-bit signed integer or is malformed
> + * 2 Special case of 9223372036854775808
> + */
I still see that comment to this function violates code style..
And comment to sql_dec_or_hex_to_i64 below too.
> diff --git a/src/box/sql/vdbe.c b/src/box/sql/vdbe.c
> index f50e389..195638e 100644
> --- a/src/box/sql/vdbe.c
> +++ b/src/box/sql/vdbe.c
> @@ -291,7 +291,7 @@ applyNumericAffinity(Mem *pRec, int bTryForInt)
> i64 iValue;
> assert((pRec->flags & (MEM_Str|MEM_Int|MEM_Real))==MEM_Str);
> if (sqlite3AtoF(pRec->z, &rValue, pRec->n)==0) return;
> - if (0==sqlite3Atoi64(pRec->z, &iValue, pRec->n)) {
> + if (0 == sql_atoi64(pRec->z, (int64_t *)&iValue, pRec->n)) {
Are you sure this cast is not redundant? If not so, why don’t use int64_t as type of iValue?
[-- Attachment #2: Type: text/html, Size: 96405 bytes --]
next prev parent reply other threads:[~2018-07-18 17:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-17 6:08 [tarantool-patches] " Kirill Yukhin
2018-07-18 1:10 ` [tarantool-patches] " n.pettik
2018-07-18 7:57 ` Kirill Yukhin
2018-07-18 17:56 ` n.pettik [this message]
2018-07-19 8:53 ` 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=19FED891-E36F-4D49-84BF-EFE30048CD46@tarantool.org \
--to=korablev@tarantool.org \
--cc=kyukhin@tarantool.org \
--cc=tarantool-patches@freelists.org \
--subject='[tarantool-patches] Re: [PATCH] sql: do not allow oversized integer literals' \
/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