Bug#17667: An attacker has the opportunity to bypass query logging.
This adds a new, local-only printf format specifier to our *printf functions
that allows us to print known-size buffers that must not be interpreted as
NUL-terminated "strings."
It uses this format-specifier to print to the log, thus fixing this
problem.
Updating data in HEAP table with BTREE index results in wrong index_length
counter value, which keeps growing after each update.
When inserting new record into tree counter is incremented by:
sizeof(TREE_ELEMENT) + key_size + tree->size_of_element
But when deleting element from tree it doesn't decrement counter by key_size:
sizeof(TREE_ELEMENT) + tree->size_of_element
This fix makes accurate allocated memory counter for tree. That is
decrease counter by key_size when deleting tree element.
The bug caused a reported index corruption in the cases when
key_cache_block_size was not a multiple of myisam_block_size,
e.g. when key_cache_block_size=1536 while myisam_block_size=1024.
- Improved solution by adding an else stetment so that do find next is avoided if erorr occurs, but we still return zero files found instaed of an error
It was impossible to create some table names on Windows
(e.g. LPT1, AUX, COM1, etc).
Fixed to pad dangerous names with thee "at" signs
(e.g. LPT1@@@, AUX@@@, COM1@@@, and so on).
- Grab the path from "configure --sysconfdir=<path>" and set it as
the first place to look for my.cnf files
Do this both in Makefiles for libmysql and mysys
- Patch provided by Francesco Riosa. Thank you!
The problem where is that Visual Studio 8 includes new security features to help write more secure code. One of these features is parameter validation. Many of the CRT functions, including lseek, assert on illegal parameter values in debug builds. They also call parameter validation callback routines that can be registered. We solve this problem by defaulting the error value to -1 and then only calling lseek if the fd != -1.
my_seek.c:
Only call lseek if the fd is not -1 on Windows
A wrong cast led to numeric overflow for data files
greater than 4GB. The parallel repair assumed end of
file after reading the amount of data that the file
was bigger than 4GB. It truncated the data file and
noted the number of records it found so far in the
index file header as the number of rows in the table.
Removing the cast fixed the problem.
I added some cosmetic changes too.
The normal repair worked because it uses a different
function to read from the data file.
