Bug #31066 Inconsistencies setting max_binlog_cache_size to 4G

Description:
If you leave max_binlog_cache_size at its default, the size reported by SHOW VARIABLES on a x86 machine is 4294967295. On an x86_64 machine, the size is reported as 18446744073709551615. Maximum is supposed to be 4GB.

When setting max_binlog_cache_size to 4G, either in my.cnf or using SET GLOBAL, SHOW VARIABLES on an x86 machine will report the size as 0. On an x86_64 machine, the size is 4294967296.

If you set the size to 4294967295, SHOW VARIABLES reports its size as 4294963200 on either and x86 or an x86_64 machine (this may, or may not be correct behavior). 

How to repeat:
To repeat, set the value in the my.cnf file like below, then restart:

[mysqld]
log-bin
max_binlog_cache_size = 4G

Or, set the sizes manually using:

mysql> SET GLOBAL max_binlog_cache_size = 4294967296;
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW VARIABLES LIKE 'max_binlog_cache_size';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| max_binlog_cache_size | 0     | 
+-----------------------+-------+

Thank you for a problem report. Verified just as described.

Affects 5.1 too. Changed version info to reflect this.

And 4.1

The 32 bit part related to bug#10206.

There also seems the same problem with the following other variables:

max_seeks_for_key
max_write_lock_count
max_join_size

Just did a short search for the value:
show variables where value = 18446744073709551615

My Version:
show variables like "version%";
+-------------------------+------------------------------------------+
| Variable_name           | Value                                    |
+-------------------------+------------------------------------------+
| version                 | 5.0.27-standard-log                      |
| version_comment         | MySQL Community Edition - Standard (GPL) |
| version_compile_machine | x86_64                                   |
| version_compile_os      | unknown-linux-gnu                        |
+-------------------------+------------------------------------------+

This is possibly a duplicate of BUG#31177.

On x86-32, sizeof(ulong) != sizeof(ulonglong)

certain sysvars are ulongs, but were bounded as ulonglong
and then cast to ulong, causing an integer-wraparound.

This is fixed by the mega-patch attached to Bug#31177