Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.2
-
None
Description
All geometries created from Geometry byte string Geometry *Geometry::construct on the server are created using little endian wkb_ndr, although there is the bit for big endian wkb_xdr and error message on the server ER_GIS_DATA_WRONG_ENDIANESS that is not used.
There are also some checks for big endian, not needed at all wkb_get_double () and wkb_get_uint():
wkb_get_uint()
|
if (bo != Geometry::wkb_xdr)
|
return uint4korr(ptr);
|
So or we need to remove the endian or we need to conclude when the geometry needs handling of byte order.
Something like this should be the patch for a function
--- a/sql/spatial.cc
|
+++ b/sql/spatial.cc
|
@@ -20,6 +20,7 @@
|
#include "spatial.h"
|
#include "gstream.h" // Gis_read_stream
|
#include "sql_string.h" // String
|
+#include <mysqld_error.h>
|
|
/* This is from item_func.h. Didn't want to #include the whole file. */
|
double my_double_round(double value, longlong dec, bool dec_unsigned,
|
@@ -267,6 +268,13 @@ Geometry *Geometry::construct(Geometry_buffer *buffer,
|
|
if (data_len < SRID_SIZE + WKB_HEADER_SIZE) // < 4 + (1 + 4)
|
return NULL;
|
+
|
+ // Check for byte order
|
+ if (uint4korr(data + SRID_SIZE) == Geometry::wkb_xdr)
|
+ {
|
+ my_error(ER_GIS_DATA_WRONG_ENDIANESS, MYF(0));
|
+ return NULL;
|
+ }
|
/* +
|
Issue is catched with MDEV-26161, where based on output of MySQL ER_GIS_DATA_WRONG_ENDIANESS is obtained (why?)
Attachments
Issue Links
- blocks
-
-
- Stalled
-