[Tile-serving] [openstreetmap/osm2pgsql] Avoid crashing on out-of-range inputs for int4 columns (#956)
Sarah Hoffmann
notifications at github.com
Mon Sep 30 14:53:19 UTC 2019
lonvia commented on this pull request.
The failures on Appveyor are odd. Looks like the artificial z-order column is not parsed correctly. That hopefully fixes itself when using the right data type for sscanf.
Nice tests. Do you mind adding them as an additional test to osm2pgsql directly with this PR? You can use `tests/test-output-pgsql-z_order.cpp` as an example.
> @@ -457,12 +457,21 @@ void table_t::escape_type(const string &value, ColumnType flags)
switch (flags) {
case COLUMN_TYPE_INT: {
// For integers we take the first number, or the average if it's a-b
- long from, to;
- int items = sscanf(value.c_str(), "%ld-%ld", &from, &to);
- if (items == 1) {
+ int64_t from, to;
+ // limit number of digits parsed to avoid undefined behaviour in sscanf
+ int items = sscanf(value.c_str(), "%18ld-%18ld", &from, &to);
My reading of the sscanf man page is that you need to use '%18Ld' here to really get a 64bit value even on 32bit machines. You also need to use 'long long' then as data type for your variables to guarantee that everything matches. This should fix the Travis fail on OSX.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/osm2pgsql/pull/956#pullrequestreview-294996083
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tile-serving/attachments/20190930/46e51f77/attachment.html>
More information about the Tile-serving
mailing list