Summary: | Problem in Turkish Locale Data (tr_TR.UTF-8 , Unicode) | ||
---|---|---|---|
Product: | glibc | Reporter: | Devrim GUNDUZ <devrim> |
Component: | localedata | Assignee: | GNU C Library Locale Maintainers <libc-locales> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | glibc-bugs |
Priority: | P2 | Flags: | fweimer:
security-
|
Version: | 2.3.4 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
Devrim GUNDUZ
2005-09-19 08:25:32 UTC
This is very likely an application bug (postgresql in this case), you need to sort it out there, not here. In case it would be a glibc bug (unlikely, e.g. towlower/towupper etc. are known to work just fine with Turkish dotless i/I and i/I with dot above), this would still be wrong bugreport here. For a bugreport here, you need to provide a self-contained testcase that uses just glibc and shows the bug, or show say in ltrace what calls return incorrect values. Otherwise everybody could claim something is a glibc bug and we'd have to debug all application bugs just in case they might be glibc bugs. Especially with Turkish i/I and case insensitivity where UTF-8 representation is one byte for one case and 2 byte for the other case (and one is ASCII, while the other is not), really many application don't handle this well. |