 Relationships |
|||||||
|
|||||||
| Anonymous | Login | 2024-04-25 22:38 UTC |
| Main | My View | View Issues | Change Log | Docs |
| Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
| ID | Category | Severity | Type | Date Submitted | Last Update | ||
| 0001004 | [1003.1(2008)/Issue 7] Base Definitions and Headers | Editorial | Enhancement Request | 2015-11-09 21:37 | 2016-07-21 16:06 | ||
| Reporter | EdSchouten | View Status | public | ||||
| Assigned To | ajosey | ||||||
| Priority | normal | Resolution | Rejected | ||||
| Status | Closed | ||||||
| Name | Ed Schouten | ||||||
| Organization | Nuxi | ||||||
| User Reference | |||||||
| Section | n/a | ||||||
| Page Number | n/a | ||||||
| Line Number | n/a | ||||||
| Interp Status | --- | ||||||
| Final Accepted Text | |||||||
| Summary | 0001004: Make *_l() complete? | ||||||
| Description |
POSIX 2008 introduced the concept of locale_t, which is pretty awesome. It reduces the reliance on global state within the C library, which I really think is the way to go. The standard added a lot of *_l() functions already, but there are quite a lot of other functions that most certainly depend on locales, but don't have an *_l() variant yet. FreeBSD and Mac OS X seem to have added a lot of these functions in the meantime. These functions are already used in the wild, for example by libc++, which requires these functions to implement a standards compliant core C++ library. The following functions already have an *_l() variant on FreeBSD that POSIX does not provide: btowc dprintf fprintf fscanf fwprintf fwscanf localeconv mbrlen mbrtowc mbsnrtowcs mbsrtowcs mbstowcs snprintf sscanf strptime strtod strtof strtoimax strtol strtold strtoll strtoull strtoumax swprintf swscanf vdprintf vfprintf vfscanf vfwprintf vfwscanf vsnprintf vsscanf vswprintf vswscanf wcrtomb wcsftime wcsnrtombs wcsrtombs wcstod wcstof wcstold wcstombs wctob FreeBSD also provides *_l() variants for the following functions, but I wonder whether it makes sense. These functions are not thread-safe to begin with and reentrant versions do exist. It may make more sense to leave then without an *_l() variant: mblen mbtowc wctomb There is also an *_l() variant for sprintf, but in my opinion we'd better not standardize it to motivate people to use snprintf instead. Finally there are some functions that clearly depend on the locale either directly or indirectly (e.g., through printf). Maybe it may make sense to add *_l() variants for these as well. fnmatch perror regcomp regexec syslog As we now have strerror_l(), it may make sense to also add localized functions for other error/information string functions: gai_strerror psiginfo psignal regerror strsignal Finally the question becomes: what do we do with stdio streams? As in, which LC_CTYPE is used when writing a wide character using putwc()? Should we introduce a putwc_l()? The same holds the other way around. What if we create a stream through open_wmemstream()? Should we have a putc_l()? On one hand that may look straight-forward to go in that direction, but on the other hand, the stream itself already stores a multibyte conversion state whose encoding is specific to the locale used. Is it even safe to switch locales while using streams? Maybe you could argue that the character set used is an inherent property of the file, and thus the stream. On systems where __STDC_ISO_10646__ is set (and wchar_t always uses the same encoding across locales), it would be pretty sweet if you could just write the following to translate a KOI8-R file to Unicode on the fly: locale_t l = newlocale(LC_CTYPE_MASK, "ru_RU.KOI8-R", 0); FILE *f = fopen_l("myfile.txt", "r", l); wchar_t wc; while ((wc = getwc(f)) != WEOF) { ... } If such an approach is taken, we may need to extend the following functions to have *_l() variants: fdopen fmemopen fopen freopen open_memstream tmpfile |
||||||
| Desired Action | Please standardize the at least the parts we can agree on. ;-) | ||||||
| Tags | No tags attached. | ||||||
| Attached Files | |||||||
|
|
|||||||
|
Relationships |
|||||||
|
|||||||
|
Notes |
|
|
(0003302) rhansen (manager) 2016-07-21 16:05 |
This was discussed during the 2016-07-21 teleconference and there was general acceptance of the concept, but the Austin Group is not a development body for new material (apart from integration issues arising from the merger of the approved standards that were the Base documents into the revision). Please submit a new bug report containing concrete wording that can be discussed during a future teleconference. See the "New Work Items" section of http://opengroup.org/austin/docs/austin_sd6.txt [^] for details of the process. |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2015-11-09 21:37 | EdSchouten | New Issue | |
| 2015-11-09 21:37 | EdSchouten | Status | New => Under Review |
| 2015-11-09 21:37 | EdSchouten | Assigned To | => ajosey |
| 2015-11-09 21:37 | EdSchouten | Name | => Ed Schouten |
| 2015-11-09 21:37 | EdSchouten | Organization | => Nuxi |
| 2015-11-09 21:37 | EdSchouten | Section | => n/a |
| 2015-11-09 21:37 | EdSchouten | Page Number | => n/a |
| 2015-11-09 21:37 | EdSchouten | Line Number | => n/a |
| 2016-04-29 06:09 | EdSchouten | Relationship added | has duplicate 0001049 |
| 2016-07-21 16:05 | rhansen | Interp Status | => --- |
| 2016-07-21 16:05 | rhansen | Note Added: 0003302 | |
| 2016-07-21 16:05 | rhansen | Resolution | Open => Rejected |
| 2016-07-21 16:06 | rhansen | Status | Under Review => Closed |
| Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |  |
