Magnus Hagander wrote:
> Tom Lane wrote:
>> Magnus Hagander <magnus@hagander.net> writes:
>>> ... The other option is to have
>>> autoconf substitute our own local version of fnmatch when this happens.
>>> How would one go about to do that in autoconf asks the autoconf n00b?
>> I'd try adding a little test program that tries to compile
>>
>> #include <fnmatch.h>
>> ...
>> n = fnmatch("foo","bar", FNM_CASEFOLD);
>>
>> and see if that succeeds.
>>
>> For extra credit, incorporate that into a new PGAC_FUNC_FNMATCH macro,
>> but I think you'd need to get Peter's help on the details --- I'm just
>> a duffer on autoconf myself.
>
> Yeah, likely that someone who knows this will make it happen a lot faster.
>
> Peter, got time to help me out with this? Thanks!
Well, FNM_CASEFOLD is not POSIX, and Autoconf thinks it's a GNU
extension, which has obviously crept into other systems. So you'd need
to use AC_FUNC_FNMATCH_GNU, but that also requires you to use the GNU
replacement implementation. (A bit stupid, but then again, if you are
trying to use GNU features, whose replacement implementation are you
going to use.)
If you google for FNM_CASEFOLD, you will get about a million hits of
other open-source projects having run into this same issue.
Then again, having looked into the libpq source now, is using fnmatch()
even appropriate here? The matching rules for https are in RFC 2818:
Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type
ispresent in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered
acceptable.)Names may contain the wildcard character * which is considered to match any single domain name
componentor component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not
bar.com.
Using fnmatch(), however, will also treat ? and [] special and it will
not follow the "any single domain name component" rule.
