| |||||||||||||
A turning point for GNU libcA turning point for GNU libcPosted Mar 28, 2012 20:11 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)In reply to: A turning point for GNU libc by josh Parent article: A turning point for GNU libc
>Why does any of the functionality you described belong in libc, rather than a specialized library?
Because libc already has to do this! glibc has to read timezone database, so it can translate between UTC and current timezones. glibc has to support all kinds of encodings for iconv to work and so on.
But every single real-world program working with Unicode has to rely on third-party libraries. Ditto for timezone handling.
>glibc already contains far more than it should. Arguably, it should contain only the bare-minimum interfaces for compatibility with standard C and POSIX; anything else ought to live in another library.
Yes, that would be one way. But it should have been done from the start, now it's just not possible because of compatibility issues.
So the next best thing is to create proper and useful interfaces so all the existing complexity is at least not wasted.
(Log in to post comments)
A turning point for GNU libc Posted Mar 29, 2012 12:43 UTC (Thu) by nix (subscriber, #2304) [Link]
Timezone conversion should definitely be in glibc. It requires a large database -- though this is now universally supplied by other sources, glibc still has to do the conversion, so it makes little sense not to expose it. The only caveat here is picking an appropriate name: the getline() fiasco showed the problems created when you pick a name that is already in wide use (general rule: if your API addition breaks TeX, please pick a better name, and do so before POSIX standardizes it).
I'm not sure about proper unicode handling: doing it right is very difficult. Even doing case conversion right is difficult, and you can already case-convert with iconv() with no new APIs, only a new convention for 'locales' whose only difference from the standard ones is that they transliterate case. (But doing it that way does seem like a kludge.)
A turning point for GNU libc Posted Mar 30, 2012 21:58 UTC (Fri) by justincormack (subscriber, #70439) [Link]
Why should a timezone database be in libc? I would rather a tz update i not require a libc update. And the locale support in libc is legacy and should go. I do not wnt locales in my low level libraries.
A turning point for GNU libc Posted Mar 30, 2012 23:46 UTC (Fri) by nix (subscriber, #2304) [Link]
The tz database *itself* is no longer installed by glibc as of 2.16 (but is still in the source tree for the sake of testing).
The tz-manipulation code must stay, because widely-used functions in the exported API use it (notably tzset(), gmtime() and localtime()).
The locale support is very definitely not legacy: the C library is where all the internationalization code is located (found in libintl on many other Unix platforms). It is part of the API and ABI, used by every single internationalized program (which is most of them, these days) and can never ever be removed. (And printf() needs locale support for international printing of the decimal point and thousands grouping characters, and for the I alternative-output-digit flag character.)
A turning point for GNU libc Posted Mar 31, 2012 10:01 UTC (Sat) by mpr22 (subscriber, #60784) [Link] setlocale() and strcoll() (among other locale-related things) are both defined as part of the 1990 and 1999 versions of the ISO C standard, and I am not aware of them having been removed from the 2011 version. Therefore, every compliant hosted implementation of the C programming language is obliged to provide setlocale() and strcoll(), and by saying you don't want locales in your low-level libraries you are saying you don't want a compliant hosted implementation of the C programming language.
A turning point for GNU libc Posted Apr 5, 2012 8:29 UTC (Thu) by nix (subscriber, #2304) [Link]
setlocale(), strcoll(), and for that matter localeconv() are, of course, still there in C11, just as they were in C99 and C89.
|
|||||||||||||