Add SQLITE_PRINTF_PRECISION_LIMIT=128000000 for sqlite3 fuzzer builds.

Add SQLITE_PRINTF_PRECISION_LIMIT=128000000 for sqlite3 fuzzer builds.

TBR=shess@chromium.org
BUG=665405
Committed: https://crrev.com/8b8df507bb85f8e398b6120e7bc7b3182966aaa8
Cr-Commit-Position: refs/heads/master@{#432172}

[mmoroz, 2016-11-15 11:17:46]

Description was changed from

==========
Add SQLITE_PRINTF_PRECISION_LIMIT=128000000 for sqlite3 fuzzer builds.

R=shess@chromium.org
BUG=665405
==========

to

==========
Add SQLITE_PRINTF_PRECISION_LIMIT=128000000 for sqlite3 fuzzer builds.

TBR=shess@chromium.org
BUG=665405
==========

[mmoroz, 2016-11-15 11:17:52]

On 2016/11/15 11:17:46, mmoroz wrote:
> Description was changed from
> 
> ==========
> Add SQLITE_PRINTF_PRECISION_LIMIT=128000000 for sqlite3 fuzzer builds.
> 
> mailto:R=shess@chromium.org
> BUG=665405
> ==========
> 
> to
> 
> ==========
> Add SQLITE_PRINTF_PRECISION_LIMIT=128000000 for sqlite3 fuzzer builds.
> 
> mailto:TBR=shess@chromium.org
> BUG=665405
> ==========

TBR

[mmoroz, 2016-11-15 11:17:56]

The CQ bit was checked by mmoroz@chromium.org

[commit-bot: I haz the power, 2016-11-15 11:18:04]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-15 13:18:54]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-15 13:18:55]

Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[mmoroz, 2016-11-15 13:31:12]

The CQ bit was checked by mmoroz@chromium.org

[commit-bot: I haz the power, 2016-11-15 13:31:34]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-15 13:53:15]

Description was changed from

==========
Add SQLITE_PRINTF_PRECISION_LIMIT=128000000 for sqlite3 fuzzer builds.

TBR=shess@chromium.org
BUG=665405
==========

to

==========
Add SQLITE_PRINTF_PRECISION_LIMIT=128000000 for sqlite3 fuzzer builds.

TBR=shess@chromium.org
BUG=665405
==========

[commit-bot: I haz the power, 2016-11-15 13:53:15]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-11-15 13:56:44]

Description was changed from

==========
Add SQLITE_PRINTF_PRECISION_LIMIT=128000000 for sqlite3 fuzzer builds.

TBR=shess@chromium.org
BUG=665405
==========

to

==========
Add SQLITE_PRINTF_PRECISION_LIMIT=128000000 for sqlite3 fuzzer builds.

TBR=shess@chromium.org
BUG=665405

Committed: https://crrev.com/8b8df507bb85f8e398b6120e7bc7b3182966aaa8
Cr-Commit-Position: refs/heads/master@{#432172}
==========

[commit-bot: I haz the power, 2016-11-15 13:56:45]

Patchset 1 (id:??) landed as
https://crrev.com/8b8df507bb85f8e398b6120e7bc7b3182966aaa8
Cr-Commit-Position: refs/heads/master@{#432172}

[Scott Hess - ex-Googler, 2016-11-15 21:18:59]

LGTM.

This would seem to make http://crbug.com/659224 not repro.  Would it make sense
to instead promote the limit to our SQLite build as a whole?  In fact, the same
can probably be said of SQLITE_MAX_SQL_LENGTH.

I would even support setting both much smaller, like
SQLITE_PRINTF_PRECISION_LIMIT around 1000 and SQLITE_MAX_SQL_LENGTH around
1000*1000, both of which seem pretty relaxed in terms of real-world usage. 
AFAICT the _only_ possible negative impact would be on WebSQL, which has been
deprecated for 6 or 7 years.

[mmoroz, 2016-11-16 12:29:11]

On 2016/11/15 21:18:59, Scott Hess wrote:
> LGTM.
> 
> This would seem to make http://crbug.com/659224 not repro.  Would it make
sense
> to instead promote the limit to our SQLite build as a whole?  In fact, the
same
> can probably be said of SQLITE_MAX_SQL_LENGTH.
> 
> I would even support setting both much smaller, like
> SQLITE_PRINTF_PRECISION_LIMIT around 1000 and SQLITE_MAX_SQL_LENGTH around
> 1000*1000, both of which seem pretty relaxed in terms of real-world usage. 
> AFAICT the _only_ possible negative impact would be on WebSQL, which has been
> deprecated for 6 or 7 years.

In general, hardening of all those limits SGTM. But I have no idea who and how
relies on that. Asking more OWNERS of projects which depend on sqlite3 would
probably make sense.