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
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 ctype.h? (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: * 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
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 ctype.h 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
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 ctype.h 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
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
* 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
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
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 ctype.h? (I know system header files should not do that because it pollutes your namespace, but older systems sometimes do that.)
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 ctype.h? (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
* 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: * 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 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
* 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
