Re: Wget and i18n
Philipp Thomas <[EMAIL PROTECTED]> writes: > * Hrvoje Niksic ([EMAIL PROTECTED]) [20010427 00:10]: > > > I think it's much simpler and safer to just disable the error. It > > served its debugging purpose; it's not really needed anymore. > > Yes, you're probably right. And it would indeed be much simpler. Please take a look at how it's handled in the current sources and tell me what you think.
Re: Wget and i18n
* Hrvoje Niksic ([EMAIL PROTECTED]) [20010427 00:10]: > I think it's much simpler and safer to just disable the error. It > served its debugging purpose; it's not really needed anymore. Yes, you're probably right. And it would indeed be much simpler. Philipp -- Penguins shall save the dinosaurs -- Handelsblatt about Linux on S/390
Re: Wget and i18n
* Drazen Kacar ([EMAIL PROTECTED]) [20010427 00:51]: > I wonder. POSIX compilation environment may not do such a thing with POSIX > headers, unless explicitely allowed by POSIX. I'm too lazy to look into AFAIK, POSIX is rather useless in this context as it is an ISO issue, with ctype.h being defined there. Philipp -- Penguins shall save the dinosaurs -- Handelsblatt about Linux on S/390
Re: Wget and i18n
Quoting Drazen Kacar ([EMAIL PROTECTED]): > Does anyone have a link to the document describing theory and > implementation of precompiled headers? As far as my experience goes, you may always switch the use of precompiled headers off. And it usually makes your life easier. -- jan +-- Jan Prikryl| vr|vis center for virtual reality and visualisation <[EMAIL PROTECTED]> | http://www.vrvis.at +--
RE: Wget and i18n
>-Original Message- >From: Drazen Kacar [mailto:[EMAIL PROTECTED]] >Sent: Thursday, April 26, 2001 7:00 PM >To: [EMAIL PROTECTED] >Subject: Re: Wget and i18n > > >Herold Heiko wrote: > >> Unfortunately, on winnt this *is* a problem. >> Visual C 5 does include ctype.h in stdio.h (or something >similar, sorry, >> memory is fading). > >Is that compliant with the C standard? No. I'd never do that for lack of knowledge - I'm no a fluent C programmer, just a guy with interest in wget and access to a (legal) Win system with VC willing to provide a binary when possible. It was jast a (somewhat) humorous remark based on the previous comment (not included) about a possible problem on *old* systems, in a context referring to systems lots older than win*. Heiko -- -- PREVINET S.p.A.[EMAIL PROTECTED] -- Via Ferretto, 1ph x39-041-5907073 -- I-31021 Mogliano V.to (TV) fax x39-041-5907087 -- ITALY
Re: Wget and i18n
Hrvoje Niksic wrote: > Drazen Kacar <[EMAIL PROTECTED]> writes: > > I wonder. POSIX compilation environment may not do such a thing > > I know. However, Wget is targeted to a superset of POSIX or for that > matter ISO C compliant machines. The header thing might be applicable to K&R compilers, as well. After all, a piece of software cannot claim to be a C compiler if it doesn't conform to some description of the C language, however old.[1] > If this error breaks compilation on > those machines without bringing much value, it goes away. I didn't mean to suggest to refuse to continue; just to emit a nice friendly message. If there are service packs or whatever that fixes the problem, it might even be useful. > > In which case configure script could advise getting a C compiler, > > just for fun. > > That would be hypocritical, given that configure defaults to Gcc. :-) You think somebody would report that mismatch? :-) [1] Documenting extensions in compiler documentation is fine. -- .-. .-.Sarcasm is just one more service we offer. (_ \ / _) |[EMAIL PROTECTED] |
Re: Wget and i18n
Drazen Kacar <[EMAIL PROTECTED]> writes: > Hrvoje Niksic wrote: > > Drazen Kacar <[EMAIL PROTECTED]> writes: > > > > > Hm. But that only prevents ctype.h from being included and not the > > > functions from being used. That's OK, but it's not foolproof. > > > > Right. And it causes problems on machines that include > > through another header file. > > I wonder. POSIX compilation environment may not do such a thing I know. However, Wget is targeted to a superset of POSIX or for that matter ISO C compliant machines. If this error breaks compilation on those machines without bringing much value, it goes away. > In which case configure script could advise getting a C compiler, > just for fun. That would be hypocritical, given that configure defaults to Gcc. :-)
Re: Wget and i18n
Hrvoje Niksic wrote: > Drazen Kacar <[EMAIL PROTECTED]> writes: > > > Hm. But that only prevents ctype.h from being included and not the > > functions from being used. That's OK, but it's not foolproof. > > Right. And it causes problems on machines that include > through another header file. I wonder. POSIX compilation environment may not do such a thing with POSIX headers, unless explicitely allowed by POSIX. I'm too lazy to look into C standard^Wdraft, but I wouldn't be surprised if C had similar requirements. In which case configure script could advise getting a C compiler, just for fun. > But perhaps this would work: > > #undef isalpha > #define isalpha ***please use ISALPHA*** The phttpd way. It should unless precompiled headers do something nasty behind your back. -- .-. .-.Sarcasm is just one more service we offer. (_ \ / _) |[EMAIL PROTECTED] |
Re: Wget and i18n
Drazen Kacar <[EMAIL PROTECTED]> writes: > Hm. But that only prevents ctype.h from being included and not the > functions from being used. That's OK, but it's not foolproof. Right. And it causes problems on machines that include through another header file. Which is why I am strongly inclined to remove that error in its current form. But perhaps this would work: #undef isalpha #define isalpha ***please use ISALPHA*** And so on.
Re: Wget and i18n
Hrvoje Niksic wrote: > Drazen Kacar <[EMAIL PROTECTED]> writes: > > > make a bunch of: > > > > #undef isalpha > > #undef isdigit > > That wouldn't serve a useful purpose since Wget doesn't use ctype > macros -- the new versions are named ISALPHA, etc. As far as I can > tell, the only reason that error exists in the first place is to > prevent ctype creeping into the sources by mistake. Hm. But that only prevents ctype.h from being included and not the functions from being used. That's OK, but it's not foolproof. OTOH, I was told that the Windows compilers usually have precompiled headers. In that case some other header might use ctype macros as implemented by the compilation environment, regardless of #undefs in the wget source or specifying #ifdef guard in the compiler invocation. Does anyone have a link to the document describing theory and implementation of precompiled headers? -- .-. .-.Sarcasm is just one more service we offer. (_ \ / _) |[EMAIL PROTECTED] |
Re: Wget and i18n
Drazen Kacar <[EMAIL PROTECTED]> writes: > > Any idea what would be a sensible way to cover this ? > > Instead of: > > #ifdef isalpha > #error > #else > ... > > make a bunch of: > > #undef isalpha > #undef isdigit > ... That wouldn't serve a useful purpose since Wget doesn't use ctype macros -- the new versions are named ISALPHA, etc. As far as I can tell, the only reason that error exists in the first place is to prevent ctype creeping into the sources by mistake.
Re: Wget and i18n
Philipp Thomas <[EMAIL PROTECTED]> writes: > * Herold Heiko ([EMAIL PROTECTED]) [20010426 18:42]: > > > bugfix), now still ctype.h is included in winnt.h, compilation fails. > > (We always knew winnt is an *old* system, but this proves it :). > > > > Any idea what would be a sensible way to cover this ? > > Does MS ctype.h have include guards? If yes, one could just define > those guards on the command line. The other alternative would be to > disable NLS support on WIN* and make the inclusion of safe-ctype.h > also depending on this. I think it's much simpler and safer to just disable the error. It served its debugging purpose; it's not really needed anymore.
Re: Wget and i18n
* Herold Heiko ([EMAIL PROTECTED]) [20010426 18:42]: > bugfix), now still ctype.h is included in winnt.h, compilation fails. > (We always knew winnt is an *old* system, but this proves it :). > > Any idea what would be a sensible way to cover this ? Does MS ctype.h have include guards? If yes, one could just define those guards on the command line. The other alternative would be to disable NLS support on WIN* and make the inclusion of safe-ctype.h also depending on this. Philipp -- Philipp Thomas <[EMAIL PROTECTED]> Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany Penguins shall save the dinosaurs -- Handelsblatt about Linux on S/390
Re: Wget and i18n
Herold Heiko wrote: > Unfortunately, on winnt this *is* a problem. > Visual C 5 does include ctype.h in stdio.h (or something similar, sorry, > memory is fading). Is that compliant with the C standard? > Any idea what would be a sensible way to cover this ? Instead of: #ifdef isalpha #error #else ... make a bunch of: #undef isalpha #undef isdigit ... It would be good to have #undefs in one "#ifdef compiler_or_OS_version", because in general it's possible that isalpha() defined by the compilation environment doesn't have anything to do with isalpha() defined by the C language, so in that case throwing #error is the right thing to do. -- .-. .-.Sarcasm is just one more service we offer. (_ \ / _) |[EMAIL PROTECTED] |
RE: Wget and i18n
>From: Philipp Thomas [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, March 06, 2001 11:02 AM >To: Hrvoje Niksic >Cc: [EMAIL PROTECTED] >Subject: Re: Wget and i18n > > >* Hrvoje Niksic ([EMAIL PROTECTED]) [20010306 10:35]: >> Also, won't this trigger an error if a system header file, say >> string.h, happens to include ? (I know system header files >> should not do that because it pollutes your namespace, but older >> systems sometimes do that.) > >Yes, it would trigger in that case. But safe-ctype was >developed for GCC >originally and as gcc is used also on old systems (one of them >the original >BSD), I guess we would have heard if safe-ctype broke things. > >Philipp Unfortunately, on winnt this *is* a problem. Visual C 5 does include ctype.h in stdio.h (or something similar, sorry, memory is fading). While this finally gave me a kick enough to upgrade to VC6 (up to the latest service pack, just to be sure to cover every new added bug er bugfix), now still ctype.h is included in winnt.h, compilation fails. (We always knew winnt is an *old* system, but this proves it :). Any idea what would be a sensible way to cover this ? Heiko -- -- PREVINET S.p.A.[EMAIL PROTECTED] -- Via Ferretto, 1ph x39-041-5907073 -- I-31021 Mogliano V.to (TV) fax x39-041-5907087 -- ITALY
Re: Wget and i18n
Philipp Thomas <[EMAIL PROTECTED]> writes: > * Hrvoje Niksic ([EMAIL PROTECTED]) [20010306 14:09]: > > > OK, then the #error stays. If noone objects, I'll modify Wget to use > > these files. > > I have the patches ready and and am about to test them. So if you > wait a bit, you'll get patches ready to apply. Excellent. Just mail them to <[EMAIL PROTECTED]>. Thanks.
Re: Wget and i18n
* Hrvoje Niksic ([EMAIL PROTECTED]) [20010306 14:09]: > OK, then the #error stays. If noone objects, I'll modify Wget to use > these files. I have the patches ready and and am about to test them. So if you wait a bit, you'll get patches ready to apply. Philipp -- Penguins shall save the dinosaurs -- Handelsblatt about Linux on S/390
Re: Wget and i18n
Philipp Thomas <[EMAIL PROTECTED]> writes: > * Hrvoje Niksic ([EMAIL PROTECTED]) [20010306 11:21]: > > > It is true that old systems use Gcc, but I wonder if anyone tests > > *new* Gcc's on old these old systems... > > Yes, they do. The patches to make gcc build on the original BSD are > only present in the current CVS GCC. OK, then the #error stays. If noone objects, I'll modify Wget to use these files. Thanks.
Re: Wget and i18n
* Hrvoje Niksic ([EMAIL PROTECTED]) [20010306 11:21]: > It is true that old systems use Gcc, but I wonder if anyone tests > *new* Gcc's on old these old systems... Yes, they do. The patches to make gcc build on the original BSD are only present in the current CVS GCC. Philipp -- Penguins shall save the dinosaurs -- Handelsblatt about Linux on S/390
Re: Wget and i18n
Philipp Thomas <[EMAIL PROTECTED]> writes: > > Is the error statement actually true, or is this only a warning > > that tries to enforce consistency of the application? > > The error statement is true. Remember that ctype.h is locale > dependent whereas safe-ctype is not. So for instance isprint > (ctype.h) and ISPRINT (safe-ctype) could well produce different > results. But that's a feature. :-) What I was asking was: is the error statement technically true -- does including ctype somehow harm the *operation* of safe-ctype? > And as the intention is to get rid of the locale dependency, you > have to block the inclusion of ctype.h. I can easily imagine an application that wants locale processing for input received by the user, and locale-independent processing for input received from the wire. Either way, the question was only to clarify things. I will likely retain the error to enforce consistency, if nothing else. > Yes, it would trigger in that case. But safe-ctype was developed for > GCC originally and as gcc is used also on old systems (one of them > the original BSD), I guess we would have heard if safe-ctype broke > things. It is true that old systems use Gcc, but I wonder if anyone tests *new* Gcc's on old these old systems...
Re: Wget and i18n
* Hrvoje Niksic ([EMAIL PROTECTED]) [20010306 10:35]: > > #ifdef isalpha > > #error "safe-ctype.h and ctype.h may not be used simultaneously" > > #else > > Is the error statement actually true, or is this only a warning that > tries to enforce consistency of the application? The error statement is true. Remember that ctype.h is locale dependent whereas safe-ctype is not. So for instance isprint (ctype.h) and ISPRINT (safe-ctype) could well produce different results. And as the intention is to get rid of the locale dependency, you have to block the inclusion of ctype.h. The caveat with using safe-ctype is, that it won't work with multibyte encodings or wchars. So in the end every use of is... does need to be checked anway. > Also, won't this trigger an error if a system header file, say > string.h, happens to include ? (I know system header files > should not do that because it pollutes your namespace, but older > systems sometimes do that.) Yes, it would trigger in that case. But safe-ctype was developed for GCC originally and as gcc is used also on old systems (one of them the original BSD), I guess we would have heard if safe-ctype broke things. Philipp -- Penguins shall save the dinosaurs -- Handelsblatt about Linux on S/390
Re: Wget and i18n
Philipp Thomas <[EMAIL PROTECTED]> writes: > Ooops, yes my fingers were a bit too fast :-) Here they are, both > safe-ctype.h and safe-ctype.c. They look good to me. The only thing I don't get is this check: > #ifdef isalpha > #error "safe-ctype.h and ctype.h may not be used simultaneously" > #else Is the error statement actually true, or is this only a warning that tries to enforce consistency of the application? Also, won't this trigger an error if a system header file, say string.h, happens to include ? (I know system header files should not do that because it pollutes your namespace, but older systems sometimes do that.)
Re: Wget and i18n
Philipp Thomas <[EMAIL PROTECTED]> writes: > * Hrvoje Niksic ([EMAIL PROTECTED]) [20010305 19:30]: > > > you leave LC_CTYPE at the default, "C" locale, gettext converts > > eight-bit characters to question marks. > > What should it do? characters > 127 are undefined in LC_CTYPE for > the "C" locale. So IMHO the only safe thing to do is to print a > question mark instead. IMHO the only reasonable thing is to pass those characters as-is, which is what it used to do, and which worked perfectly. I hoped the times when the default action was to strip the eighth bit were behind us. Even the GNU coding standards recommend all applications to be 8-bit clean.
Re: Wget and i18n
* Hrvoje Niksic ([EMAIL PROTECTED]) [20010305 19:30]:
> you leave LC_CTYPE at the default, "C" locale, gettext converts
> eight-bit characters to question marks.
What should it do? characters > 127 are undefined in LC_CTYPE for the "C"
locale. So IMHO the only safe thing to do is to print a question mark
instead.
> > Look for yourself :) I've attached safe-ctype.h from libiberty.
>
> Apparently you forgot the actual attachment. :-)
Ooops, yes my fingers were a bit too fast :-) Here they are, both
safe-ctype.h and safe-ctype.c.
Philipp
--
Philipp Thomas <[EMAIL PROTECTED]>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany
Penguins shall save the dinosaurs
-- Handelsblatt about Linux on S/390
/* replacement macros.
Copyright (C) 2000 Free Software Foundation, Inc.
Contributed by Zack Weinberg <[EMAIL PROTECTED]>.
This file is part of the libiberty library.
Libiberty is free software; you can redistribute it and/or
modify it under the terms of the GNU Library General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.
Libiberty is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Library General Public License for more details.
You should have received a copy of the GNU Library General Public
License along with libiberty; see the file COPYING.LIB. If
not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA. */
/* This is a compatible replacement of the standard C library's
with the following properties:
- Implements all isxxx() macros required by C99.
- Also implements some character classes useful when
parsing C-like languages.
- Does not change behavior depending on the current locale.
- Behaves properly for all values in the range of a signed or
unsigned char.
To avoid conflicts, this header defines the isxxx functions in upper
case, e.g. ISALPHA not isalpha. */
#ifndef SAFE_CTYPE_H
#define SAFE_CTYPE_H
#ifdef isalpha
#error "safe-ctype.h and ctype.h may not be used simultaneously"
#else
/* Categories. */
enum {
/* In C99 */
_sch_isblank = 0x0001, /* space \t */
_sch_iscntrl = 0x0002, /* nonprinting characters */
_sch_isdigit = 0x0004, /* 0-9 */
_sch_islower = 0x0008, /* a-z */
_sch_isprint = 0x0010, /* any printing character including ' ' */
_sch_ispunct = 0x0020, /* all punctuation */
_sch_isspace = 0x0040, /* space \t \n \r \f \v */
_sch_isupper = 0x0080, /* A-Z */
_sch_isxdigit = 0x0100, /* 0-9A-Fa-f */
/* Extra categories useful to cpplib. */
_sch_isidst = 0x0200, /* A-Za-z_ */
_sch_isvsp= 0x0400, /* \n \r */
_sch_isnvsp = 0x0800, /* space \t \f \v \0 */
/* Combinations of the above. */
_sch_isalpha = _sch_isupper|_sch_islower,/* A-Za-z */
_sch_isalnum = _sch_isalpha|_sch_isdigit,/* A-Za-z0-9 */
_sch_isidnum = _sch_isidst|_sch_isdigit, /* A-Za-z0-9_ */
_sch_isgraph = _sch_isalnum|_sch_ispunct,/* isprint and not space */
_sch_iscppsp = _sch_isvsp|_sch_isnvsp/* isspace + \0 */
};
/* Character classification. */
extern const unsigned short _sch_istable[256];
#define _sch_test(c, bit) (_sch_istable[(c) & 0xff] & (bit))
#define ISALPHA(c) _sch_test(c, _sch_isalpha)
#define ISALNUM(c) _sch_test(c, _sch_isalnum)
#define ISBLANK(c) _sch_test(c, _sch_isblank)
#define ISCNTRL(c) _sch_test(c, _sch_iscntrl)
#define ISDIGIT(c) _sch_test(c, _sch_isdigit)
#define ISGRAPH(c) _sch_test(c, _sch_isgraph)
#define ISLOWER(c) _sch_test(c, _sch_islower)
#define ISPRINT(c) _sch_test(c, _sch_isprint)
#define ISPUNCT(c) _sch_test(c, _sch_ispunct)
#define ISSPACE(c) _sch_test(c, _sch_isspace)
#define ISUPPER(c) _sch_test(c, _sch_isupper)
#define ISXDIGIT(c) _sch_test(c, _sch_isxdigit)
#define ISIDNUM(c) _sch_test(c, _sch_isidnum)
#define ISIDST(c) _sch_test(c, _sch_isidst)
#define IS_VSPACE(c)_sch_test(c, _sch_isvsp)
#define IS_NVSPACE(c) _sch_test(c, _sch_isnvsp)
#define IS_SPACE_OR_NUL(c) _sch_test(c, _sch_iscppsp)
/* Character transformation. */
extern const unsigned char _sch_toupper[256];
extern const unsigned char _sch_tolower[256];
#define TOUPPER(c) _sch_toupper[(c) & 0xff]
#define TOLOWER(c) _sch_tolower[(c) & 0xff]
#endif /* no ctype.h */
#endif /* SAFE_CTYPE_H */
/* replacement macros.
Copyright (C) 2000 Free Software Foundation, Inc.
Contributed by Zack Weinberg <[EMAIL PROTECTED]>.
This file is part of the libiberty library.
Libiberty is free software; you can redistribute it and/or
modify it under the terms of the GNU Library General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at yo
Re: Wget and i18n
Philipp Thomas <[EMAIL PROTECTED]> writes: > * Hrvoje Niksic ([EMAIL PROTECTED]) [20010305 18:44]: > > > Yes. I hate them for making that change, but apparently it's > > allowed (or even required, I forget now) by the applicable > > standards. > > It is required. LC_MESSAGES and LC_CTYPE are two different and > independent locale categories. Of course they are. My gripe is that, beginning with glibc 2.2, if you leave LC_CTYPE at the default, "C" locale, gettext converts eight-bit characters to question marks. It has _nothing_ to do with LC_MESSAGES being different and independent. (I already know that, and that's why I was _intentionally_ setting LC_MESSAGES only.) > > If the sage-ctype thing is not too ugly, using it would be > > acceptable. > > Look for yourself :) I've attached safe-ctype.h from libiberty. Apparently you forgot the actual attachment. :-)
Re: Wget and i18n
* Hrvoje Niksic ([EMAIL PROTECTED]) [20010305 18:44]: > Yes. I hate them for making that change, but apparently it's allowed > (or even required, I forget now) by the applicable standards. It is required. LC_MESSAGES and LC_CTYPE are two different and independent locale categories. > Philipp, you've nailed it down -- the ctype change is the reason why I > didn't want to make that change. That's what I thought :) Seems like very few authors took heed of the implications that the locale support in the standard C library brought with it. As a result, nearly every package that supports i18n and uses ctype.h macros either needs to be audited very closely (there could be places that locale dependency is wanted) or needs to use a locale independent ctype.h replacement. > If the sage-ctype thing is not too ugly, using it would be acceptable. Look for yourself :) I've attached safe-ctype.h from libiberty. > If/when you're making the change, don't forget to make the patch > against the latest CVS sources. I'm just now checking out the CVS tree and'll make the patch against it. > Thanks for your effort. Well, as it's in my direct interest to have a correct package for our distribution, this comes naturally ;-) Philipp -- Philipp Thomas <[EMAIL PROTECTED]> Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany Penguins shall save the dinosaurs -- Handelsblatt about Linux on S/390
Re: Wget and i18n
Dan Harkless <[EMAIL PROTECTED]> writes: > Philipp Thomas <[EMAIL PROTECTED]> writes: > > I haven't checked development versions, but wget 1.6 needs a small > > patch to make it display correctly in locales different from > > C/POSIX under glibc2.2 and up. Specifically, LC_CTYPE has to be > > set along with LC_MESSAGES to correctly set the terminal output > > charset. Yes. I hate them for making that change, but apparently it's allowed (or even required, I forget now) by the applicable standards. > > Now this has additional implications as now the behaviour of the > > ctype.h macros changes. One solution for this would be to use the > > safe-ctype.h header created for GCC to circumvent exactly this > > problem. safe-ctype.h defines all the necessary stuff but based on > > the C/POSIX locale and is *not* locale dependent. If this is an > > acceptable solution for you, I could do the changes and then send > > you the diffs. Philipp, you've nailed it down -- the ctype change is the reason why I didn't want to make that change. If the sage-ctype thing is not too ugly, using it would be acceptable. If/when you're making the change, don't forget to make the patch against the latest CVS sources. Thanks for your effort.
Re: Wget and i18n
Please send things like this to [EMAIL PROTECTED], as is documented, not to any one individual (I'm cc'ing this reply there). I'll have to let the non-U.S. folks evaluate the below. Philipp Thomas <[EMAIL PROTECTED]> writes: > Dan, > > I haven't checked development versions, but wget 1.6 needs a small patch > to make it display correctly in locales different from C/POSIX under > glibc2.2 and up. Specifically, LC_CTYPE has to be set along with LC_MESSAGES > to correctly set the terminal output charset. I've included that patch at > the end. > > Now this has additional implications as now the behaviour of the ctype.h > macros changes. One solution for this would be to use the safe-ctype.h > header created for GCC to circumvent exactly this problem. safe-ctype.h > defines all the necessary stuff but based on the C/POSIX locale and is *not* > locale dependent. If this is an acceptable solution for you, I could do the > changes and then send you the diffs. > > Philipp > > --- src/main.c.original Thu Mar 1 21:36:23 2001 > +++ src/main.cThu Mar 1 21:37:24 2001 > @@ -90,6 +90,7 @@ > makes http_atotm() malfunction. */ > #ifdef LC_MESSAGES >setlocale (LC_MESSAGES, ""); > + setlocale (LC_CTYPE, ""); > #else >setlocale (LC_ALL, ""); > #endif > > > > -- > Philipp Thomas <[EMAIL PROTECTED]> > Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany > > Penguins shall save the dinosaurs > -- Handelsblatt about Linux on S/390 --- Dan Harkless| To help prevent SPAM contamination, GNU Wget co-maintainer | please do not mention this email http://sunsite.dk/wget/ | address in Usenet posts -- thank you.
