Fix wrong value of type YEAR on big endian environment.

[junaruga]

This PR for #916 issue "1.2".

I checked it like this.

diff --git a/ext/mysql2/result.c b/ext/mysql2/result.c
index ccb49a5..b2d4c87 100644
--- a/ext/mysql2/result.c
+++ b/ext/mysql2/result.c
@@ -413,15 +413,25 @@ static VALUE rb_mysql_result_fetch_row_stmt(VALUE self, MYSQL_FIELD * fields, co
           }
           break;
         case MYSQL_TYPE_SHORT:        // short int
+        case MYSQL_TYPE_YEAR:         // short int
+          printf("debug rb_mysql_result_fetch_row_stmt type: [%d]\n", result_buffer->buffer_type);
           if (result_buffer->is_unsigned) {
             val = UINT2NUM(*((unsigned short int*)result_buffer->buffer));
+            printf("debug rb_mysql_result_fetch_row_stmt type: [%d], unsinged. buffer: [%d], length: [%lu], buffer_length: [%lu]\n",
+              result_buffer->buffer_type,
+              *((unsigned short int*)result_buffer->buffer),
+              *((unsigned long*)result_buffer->length), result_buffer->buffer_length);
           } else  {
             val = INT2NUM(*((short int*)result_buffer->buffer));
+            printf("debug rb_mysql_result_fetch_row_stmt type: [%d] singed. [%d], length: [%lu], buffer_length: [%lu]\n",
+              result_buffer->buffer_type,
+              *((short int*)result_buffer->buffer),
+              *((unsigned long*)result_buffer->length), result_buffer->buffer_length);
           }

The result is like this on little endian. (MYSQL_TYPE_YEAR value is 13.)

debug rb_mysql_result_fetch_row_stmt type: [13]
debug rb_mysql_result_fetch_row_stmt type: [13], unsinged. buffer: [2009], length: [2], buffer_length: [4]

The value is 131661824 on big endian environment as you know.

Seeing the source code in mariadb-connector-c v3.0.2 (v3.0.3 is not released yet), the type year looks defined as short int.

https://github.com/MariaDB/mariadb-connector-c/blob/v3.0.2/libmariadb/ma_stmt_codec.c#L443

void ps_fetch_int16(MYSQL_BIND *r_param, const MYSQL_FIELD * const field,
                                unsigned char **row)
...
    case MYSQL_TYPE_YEAR:
    case MYSQL_TYPE_SHORT:
        ps_fetch_from_1_to_8_bytes(r_param, field, row, 2);

https://github.com/MariaDB/mariadb-connector-c/blob/v3.0.2/libmariadb/ma_stmt_codec.c#L254

r_param->is_unsigned ? NUMERIC_TRUNCATION(val, 0, UINT_MAX16) : NUMERIC_TRUNCATION(val, INT_MIN16, INT_MAX16)

https://github.com/MariaDB/mariadb-connector-c/blob/v3.0.2/include/ma_global.h#L549-L551

#define INT_MIN16       (~0x7FFF)
#define INT_MAX16       0x7FFF
#define UINT_MAX16 0xFFFF

unsigned YEAR: between 0 (0x00 0x00) and UINT_MAX16 (0xff 0xff) that is unsigned int short
signed YEAR: (I am not sure signed YEAR is possible): between INT_MIN16 and INT_MAX16: int short

I tested this patch on big endian environment. And that's okay.
But I want to know why it was "int" previously.
The definition of YEAR is different between mariadb-connector-c, MySQL server and Mariadb server?
Do you remember it?

Thank you.

[sodabrew]

According to https://dev.mysql.com/doc/refman/5.7/en/c-api-prepared-statement-data-structures.html YEAR is an unsigned int field in the MYSQL_TIME structure.

According to https://dev.mysql.com/doc/refman/5.7/en/c-api-prepared-statement-type-codes.html it's a short int, but should have type MYSQL_TYPE_SHORT!

[sodabrew]

To make this PR internally consistent, please adjust https://github.com/junaruga/mysql2/blob/8ef0b8fd78b3b95b6e8afb154e931f316c2be40b/ext/mysql2/result.c#L236 as well.

It looks like the right change, but it's not clear to me if this is another client library incompatibility. Let's one of us run down the equivalent code in the MySQL Connector/C to confirm.

[junaruga]

Thanks for the information.

According to https://dev.mysql.com/doc/refman/5.7/en/c-api-prepared-statement-data-structures.html YEAR is an unsigned int field in the MYSQL_TIME structure.

According to https://dev.mysql.com/doc/refman/5.7/en/c-api-prepared-statement-type-codes.html it's a short int, but should have type MYSQL_TYPE_SHORT!

That's interesting.
And the official information for MySQL is what I wanted to know.
Thanks for that.

To make this PR internally consistent, please adjust https://github.com/junaruga/mysql2/blob/8ef0b8fd78b3b95b6e8afb154e931f316c2be40b/ext/mysql2/result.c#L236 as well.

Okay, I will change the part too. And let me run it with mariadb-connector-c on big endian evironment at first.

It looks like the right change, but it's not clear to me if this is another client library incompatibility. Let's one of us run down the equivalent code in the MySQL Connector/C to confirm.

You meant client logic for mysql-server?
https://github.com/mysql/mysql-server/tree/5.7/client

I found the C++ connector on MySQL right now, though I do not know "MySQL Connector/C".
https://github.com/mysql/mysql-connector-cpp

[sodabrew]

The download bundles for the MySQL Connector/C are here: https://dev.mysql.com/downloads/connector/c/

Looking for the source code repo.

[junaruga]

Okay, I will change the part too. And let me run it with mariadb-connector-c on big endian evironment at first.

Checked. that's okay!

Let's proceed it.

[sodabrew]

Remind myself to mark this for cherry-pick to 0.4.x as well.

[junaruga]

Looking for the source code repo.

I tried to check "MySQL Connector/C" seeing below related issues on MySQL bug tracking system.
So far, I have no idea.

https://bugs.mysql.com/search.php?cmd=display&bug_type[]=Connector%2FC&status[]=Active&os=0&bug_age=0&last_updated=0&order_by=php_version&direction=ASC&limit=30&mine=0&defect_class=all&workaround_viability=all&impact=all&fix_risk=all&fix_effort=all&reorder_by=php_version

[junaruga]

Thanks for the merging!