charset2upper broken

From: Steve French
Date: Mon May 22 2006 - 17:18:22 EST

Charset2upper is broken, at least for utf8 (see line 41 of nls_utf8.c) Seems straightforward to fix it for the key characters a-z (0x61-0x7a), unless the uppercasing rules are stranger than I think - especially since other places have it right e.g. nls_base.c seems to have it right in its charset2upper.

I need to uppercase passwords for cifs to be able to mount to older servers (e.g. win9x and OS/2) but since I can't tell that utf8->charset2upper is broken I can't know when to fall back to the simpleminded way of uppercasing that smbfs does.

I wish we could make theis charset2upper (and charset2lower probably) optional so it could be set to null when broken or at least return an error for those cp that are broken such as utf8 so we could fall back ... (and unfortunately utf8 is the default ...)

Apparently this breaks other guys too see below ...

On Sat, Oct 29, 2005 at 12:07:40AM +0900, OGAWA Hirofumi wrote:
>/ OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> writes:/
>/ /
>/ > Horms <horms@xxxxxxxxxxxx> writes:/
>/ >/
>/ >> static struct nls_table table = {/
>/ >> .charset = "utf8",/
>/ >> .uni2char = uni2char,/
>/ >> .char2uni = char2uni,/
>/ >> .charset2lower = identity, /* no conversion *//
>/ >> .charset2upper = identity,/
>/ >> .owner = THIS_MODULE,/
>/ >> };/
>/ >>/
>/ >> I guess it is charset2lower or charset2upper that vfat is calling,/
>/ >> which make no conversion, thus leading to the problem I outlined above./
>/ >>/
>/ >> My question is: Is this behaviour correct, or is it a bug?/
>/ >/
>/ > This is known bug. For fixing this bug cleanly, we will need to much/
>/ > change the both of nls and filesystems./
>/ /
>/ And fatfs has "utf8" option, probably the behavior is preferable than/
>/ "iocharset=utf8". However, unfortunately "utf8" has problem too./

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at