Re: strcasecmp raises its...
On 5/19/22 7:54 PM, Stefan Eissing wrote: > > >> Am 19.05.2022 um 17:20 schrieb Ruediger Pluem : >> >> >>> >>> +1 from me for replacing our protocol+config handling code with the >>> ap_cstr_casecmp(). >> >> +1. Just to mention: Christophe already did quite some work in this area. > > Thanks, Christophe. > > For my understanding: the code in APR for tables uses strcasecmp() and I am > probably just too stupid to see where this is redefined? > >From my point of view apr_tables use strcasecmp and this is not redefined. I >guess one of the reasons is that the apr_tables stuff has been there forever in APR and the apr_cstr stuff only came into APR 2016 and the code of apr_tables was not adjusted after this. The other reason at least for 1.x might be concerns that switching to apr_cstr might change the behavior of apr_tables in a way that is incompatible with the versioning rules of APR. But this is a discussion for dev@apr. Regards Rüdiger
Re: strcasecmp raises its...
> Am 19.05.2022 um 17:20 schrieb Ruediger Pluem : > > > > On 5/19/22 5:15 PM, Stefan Eissing wrote: >> >> >>> Am 19.05.2022 um 16:44 schrieb Joe Orton : >>> >>> On Wed, May 18, 2022 at 05:34:22PM +0200, Ruediger Pluem wrote: On 5/18/22 4:55 PM, Joe Orton wrote: > I think for httpd it is only safe and sane to run httpd with LANG=C, we > do this in the default service scripts in Fedora/RHEL for a very long > time. Other than the protocol parsing issues you can get in non-C > locales, you can also get "surprises" when sort order can change with > the system locale, impacting e.g. config file load ordering and more. Don't you need a locale sensitive case insensitive string comparison in case of case blind file systems which support extended latin characters? I know these Germans with their Umlaute :-). >>> >>> Heh. Well, I got away with it so far :) >>> > So IMHO it is probably sufficient & simpler to adjust apachectl to set > LANG=C rather than trying to eliminate strcasecmp, and add another > strcasecmp() reimplementation in APR, in this case. We already have this implementation in APR and we use the httpd one which is just a forward port from APR to httpd until we require a sufficient recent APR version in several places. The question is just if we should use them everywhere and thus do the correct thing no matter what locale is set. >>> >>> Ah, I missed that, thanks. >>> >>> +1 from me on doing replacement of strcasecmp() with the >>> locale-insensitive versions then. At least with config options, protocol >>> data, it is definitely right. >>> >> >> +1 from me for replacing our protocol+config handling code with the >> ap_cstr_casecmp(). > > +1. Just to mention: Christophe already did quite some work in this area. Thanks, Christophe. For my understanding: the code in APR for tables uses strcasecmp() and I am probably just too stupid to see where this is redefined? Kind Regards, Stefan > > Regards > > Rüdiger
Re: strcasecmp raises its...
On 5/19/22 5:15 PM, Stefan Eissing wrote: > > >> Am 19.05.2022 um 16:44 schrieb Joe Orton : >> >> On Wed, May 18, 2022 at 05:34:22PM +0200, Ruediger Pluem wrote: >>> On 5/18/22 4:55 PM, Joe Orton wrote: I think for httpd it is only safe and sane to run httpd with LANG=C, we do this in the default service scripts in Fedora/RHEL for a very long time. Other than the protocol parsing issues you can get in non-C locales, you can also get "surprises" when sort order can change with the system locale, impacting e.g. config file load ordering and more. >>> >>> Don't you need a locale sensitive case insensitive string comparison in >>> case of case blind file systems which support extended >>> latin characters? I know these Germans with their Umlaute :-). >> >> Heh. Well, I got away with it so far :) >> So IMHO it is probably sufficient & simpler to adjust apachectl to set LANG=C rather than trying to eliminate strcasecmp, and add another strcasecmp() reimplementation in APR, in this case. >>> >>> We already have this implementation in APR and we use the >>> httpd one which is just a forward port from APR to httpd until we require a >>> sufficient recent APR version in several places. >>> The question is just if we should use them everywhere and thus do the >>> correct thing no matter what locale is set. >> >> Ah, I missed that, thanks. >> >> +1 from me on doing replacement of strcasecmp() with the >> locale-insensitive versions then. At least with config options, protocol >> data, it is definitely right. >> > > +1 from me for replacing our protocol+config handling code with the > ap_cstr_casecmp(). +1. Just to mention: Christophe already did quite some work in this area. Regards Rüdiger
Re: strcasecmp raises its...
> Am 19.05.2022 um 16:44 schrieb Joe Orton : > > On Wed, May 18, 2022 at 05:34:22PM +0200, Ruediger Pluem wrote: >> On 5/18/22 4:55 PM, Joe Orton wrote: >>> I think for httpd it is only safe and sane to run httpd with LANG=C, we >>> do this in the default service scripts in Fedora/RHEL for a very long >>> time. Other than the protocol parsing issues you can get in non-C >>> locales, you can also get "surprises" when sort order can change with >>> the system locale, impacting e.g. config file load ordering and more. >> >> Don't you need a locale sensitive case insensitive string comparison in case >> of case blind file systems which support extended >> latin characters? I know these Germans with their Umlaute :-). > > Heh. Well, I got away with it so far :) > >>> So IMHO it is probably sufficient & simpler to adjust apachectl to set >>> LANG=C rather than trying to eliminate strcasecmp, and add another >>> strcasecmp() reimplementation in APR, in this case. >> >> We already have this implementation in APR and we use the >> httpd one which is just a forward port from APR to httpd until we require a >> sufficient recent APR version in several places. >> The question is just if we should use them everywhere and thus do the >> correct thing no matter what locale is set. > > Ah, I missed that, thanks. > > +1 from me on doing replacement of strcasecmp() with the > locale-insensitive versions then. At least with config options, protocol > data, it is definitely right. > +1 from me for replacing our protocol+config handling code with the ap_cstr_casecmp(). Cheers, Stefan
Re: strcasecmp raises its...
On Wed, May 18, 2022 at 05:34:22PM +0200, Ruediger Pluem wrote: > On 5/18/22 4:55 PM, Joe Orton wrote: > > I think for httpd it is only safe and sane to run httpd with LANG=C, we > > do this in the default service scripts in Fedora/RHEL for a very long > > time. Other than the protocol parsing issues you can get in non-C > > locales, you can also get "surprises" when sort order can change with > > the system locale, impacting e.g. config file load ordering and more. > > Don't you need a locale sensitive case insensitive string comparison in case > of case blind file systems which support extended > latin characters? I know these Germans with their Umlaute :-). Heh. Well, I got away with it so far :) > > So IMHO it is probably sufficient & simpler to adjust apachectl to set > > LANG=C rather than trying to eliminate strcasecmp, and add another > > strcasecmp() reimplementation in APR, in this case. > > We already have this implementation in APR and we use the > httpd one which is just a forward port from APR to httpd until we require a > sufficient recent APR version in several places. > The question is just if we should use them everywhere and thus do the correct > thing no matter what locale is set. Ah, I missed that, thanks. +1 from me on doing replacement of strcasecmp() with the locale-insensitive versions then. At least with config options, protocol data, it is definitely right. Regards, Joe
Final reminder: ApacheCon North America call for presentations closing soon
[Note: You're receiving this because you are subscribed to one or more Apache Software Foundation project mailing lists.] This is your final reminder that the Call for Presetations for ApacheCon North America 2022 will close at 00:01 GMT on Monday, May 23rd, 2022. Please don't wait! Get your talk proposals in now! Details here: https://apachecon.com/acna2022/cfp.html --Rich, for the ApacheCon Planners
Re: strcasecmp raises its...
On 5/18/22 7:17 PM, Nick Kew wrote: > >> On 18 May 2022, at 16:34, Ruediger Pluem wrote: >> >> Rüdiger > > What locale are YOU in there? Any attempt at locale is going to have to draw > lines: de_DE.UTF-8 > what are the rules for when Ruediger == Rüdiger? There can be none. Because I can transcribe ü to ue , but not every ue is an ü the other way around. Regards Rüdiger
