Bug 3949 - wcwidth fails to be standards-compliant
Summary: wcwidth fails to be standards-compliant
Status: REOPENED
Alias: None
Product: uClibc
Classification: Unclassified
Component: Standard Compliance (show other bugs)
Version: 0.9.32
Hardware: All Linux
: P5 minor
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-04 11:16 UTC by Kiyoshi Aman
Modified: 2011-07-04 22:42 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Kiyoshi Aman 2011-07-04 11:16:19 UTC 
The wcwidth function (and wcswidth, for that matter, since uClibc's wcwidth is implemented in terms of wcswidth) fails to be standards compliant. The following test should emit 'e-acute is 1 wide' on conforming implementations; uClibc's instead emits 'e-acute is -1 wide':

#include <stdio.h>
#include <wchar.h>

void main(void) {
  printf("e-acute is %d wide\n", wcwidth(0xe9));
}
Comment 1 Kiyoshi Aman 2011-07-04 11:18:07 UTC 
I should note, http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c conforms to standards and is suitably licensed such that it could replace uClibc's implementation.
Comment 2 Kiyoshi Aman 2011-07-04 11:42:23 UTC 
After further discussion, I'm going to take this up with Alpine Linux's libc team due to their disabling of locales.
Comment 3 Kiyoshi Aman 2011-07-04 22:42:06 UTC 
Reopening because it makes no sense for wc(s)width to default to ASCII when locales are disabled. ASCII is not 'widechar' at all, particularly when the existing str* functions in string.h handle ASCII just fine.