Bug #16678 FORMAT gives wrong result if client run with default-character-set=utf8
Submitted: 20 Jan 2006 16:40 Modified: 8 Mar 2006 16:23
Reporter: Victoria Reznichenko Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:5.0 OS:Linux (linux)
Assigned to: Sergei Glukhov CPU Architecture:Any

[20 Jan 2006 16:40] Victoria Reznichenko
Description:
If I run client with --default-character-set=utf8 (if character_set_connection=utf8) FORMAT gives wrong result (truncates the output).

How to repeat:
1. create table
2. specify character_set_connection=utf8 (or connect with mysql --default-character-set=utf8)
3. execute SELECT query and check result
[21 Feb 2006 12:27] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/2968
[1 Mar 2006 12:56] Alexander Barkov
It looks that the patch allocates too many bytes if
the first argument is a multibyte string.
This code should probably be better:

uint char_length= args[0]->max_length / args[0]->collation.collation->mbmaxlen;
max_length=(char_length+(char_length-args[0]->decimals)/3) * collation.collation->mbmaxlen;
[1 Mar 2006 16:08] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/3338
[2 Mar 2006 6:52] Alexander Barkov
Ok to push.
[6 Mar 2006 8:48] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/3483
[6 Mar 2006 8:54] Sergei Glukhov
Fixed in 5.0.20
[8 Mar 2006 16:23] Paul DuBois
Noted in 5.0.20 changelog.

The <literal>FORMAT()</literal> function returned an incorrect
result when the client's
<literal>character_set_connection</literal> value was
<literal>utf8</literal>. (Bug #16678)
[17 Apr 2006 7:15] Vladimir Zheleznyak
Thank you for fixing this bug. 
We'd like to note that the same bug persists in the following functions:

SELECT INET_NTOA(3520061480);
SELECT PASSWORD('badpwd');
SELECT SHA('abc');
SELECT SHA1('abc');
SELECT MD5('testing');
SELECT OLD_PASSWORD('str')
SELECT 38.8, CONCAT(38.8);
SELECT DATE_ADD('1998-01-02', INTERVAL 31 DAY);
SELECT ADDDATE('1998-01-02', INTERVAL 31 DAY);
SELECT ADDTIME('01:00:00.999999', '02:00:00.999998');
SELECT '1997-12-31 23:59:59' + INTERVAL 1 SECOND;
SELECT DAYNAME('1998-02-05');
SELECT DATE_SUB('1998-01-02', INTERVAL 31 DAY);
SELECT SUBDATE('1998-01-02', INTERVAL 31 DAY);
SELECT SUBTIME('1997-12-31 23:59:59.999999','1 1:1:1.000002');
SELECT TIMESTAMPADD(MINUTE,1,'2003-01-02');
SELECT TIME_FORMAT('100:00:00', '%H %k %h %I %l');
[13 May 2006 9:19] Sergei Glukhov
I have checked these functions and can't repeat the bug. Could you provide more cleare test case?
[19 May 2006 7:02] Vladimir Zheleznyak
After connecting to the server we execute 'SET NAMES UTF8' then trying to execute SQL statement using mysql_real_query, for example 
SELECT OLD_PASSWORD('str')
The result produced by this query is '789ee25b2631e00a'. It is 16 symbols length. Function mysql_fetch_field_direct returns LengthInBytes = 16, but for UTF8 string this value isn't correct. We think that LengthInBytes must be 16 * 3 = 48 bytes.