httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: "locale" project
Date Fri, 19 Dec 1997 18:19:33 GMT
On Fri, 19 Dec 1997, [KOI8-R] áÎÄÒÅÊ þÅÒÎÏ× wrote:

> On Fri, 19 Dec 1997, Dean Gaudet wrote:
> > I suspect there will be compiler warning issues because C library
> > functions use naked "char".  The workaround will likely to be to use "gcc
> > -funsigned-char -Wall", or whatever the equiv is on whatever other ANSI
> > compiler we use.  Note that this is just a warning issue -- not
> > necessarily a correctness issue.  (Although the library could be whacked.) 
> It is the reason why "typedef ... uchar" is not really needed, because it
> be backed by -funsigned-char in anycase as workaround of massive warnings.
> -funsigned-char alone seems enough.

Apache can be compiled by an arbitrary ANSI C compiler, not just gcc, so
this isn't a complete solution. 

> > A big worry here is that setlocale() is an expensive function.  On
> > Solaris, for example, it involves reading a file off disk.  So we can't
> > just switch locales at will.  It's unfortunate, but it's not possible for
> > a POSIX program to exist in two locales at once.
> One of the ways can be fork as many times as locales used and do all
> locale-specific work in subprocesses.

This is apache we're talking about, performance is a huge issue.  I don't
think we wan't to be forking more processes just to be doing things like

> > - (PR#754) struct tm does not include a time zone on all systems, we
> > assume it does.  It's entirely possible that we'll need our own strftime() 
> > replacement.
> Oh, no! Apache already replaces too many standard functions. Is is time
> now for Apache-libc? Lets do it only for systems which really needs them,
> not for all systems as for snprintf f.e.

You and I have argued this one before -- you want a tiny memory image on
FreeBSD where you happen to have most of the functionality current apache
wants.  I (and others) want portable code.  Apache replaces functions that
are broken or missing on enough systems that we can't ensure complete
portability.  We value portability -- we don't just want to run on freebsd
and linux.  I think in this case the C library is sorely lacking -- it
should be possible on a per-call basis to supply a locale. 

The systems I deal with can easily handle the extra overlap of 100k or
200k library code.  Many webservers are dedicated machines.  Apache isn't
about to start entering the embedded systems market, our code is bloated

The C library is poorly designed, POSIX isn't helping it at all.  We
pretty much have to replace all the string and allocation functions
because we need better resource management and more functionality.  It's a
similar step to start replacing the locale functions because we need
better locale management. 

> > - I'm certain we have assumptions that isalpha(c) is the same as c == 'a'
> > || c == 'b' || ... || c == 'z' (and the upper case letters).  When in
> > truth, isalpha(c) can also be true for various 8-bit characters in most
> > non-"C" locales.  For example, in "ISO-8859-1", isalpha(192) is TRUE. 
> > This has to be fixed. 
> Unless we switch locale from "C", this assumption is true, but if we
> switch somewhere, it is false. I don't think that Apache as daemon must
> run itself under locale different than "C", but forked modules can switch
> locale instead.

We don't fork modules. 

One more thing to add:  locale is a global setting, in a threaded port we
can't switch locales at all. 


View raw message