Xref: utzoo comp.sys.atari.st:17759 comp.lang.c:19927
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.sys.atari.st,comp.lang.c
Subject: Re: string comparisons in C
Keywords: C, atari st, mark williams
Message-ID: <10533@smoke.BRL.MIL>
Date: 15 Jul 89 05:05:29 GMT
References: <44672745.14a1f@gtephx.UUCP> <12689@bloom-beacon.MIT.EDU>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 18

In article <12689@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes:
>In article <44672745.14a1f@gtephx.UUCP> covertr@gtephx.UUCP (Richard E. Covert) writes:
>>P.S. Does anyone know if pnmatch() is implemented on other C compilers??
>No vendor should provide a routine named "pnmatch."

That's based on a misunderstanding.  The actual constraint is that a
vendor is not supposed to interfere with an application's having its
own function (or external variable, or whatever) named "pnmatch".
Such a vendor-supplied function can be included in the standard C
library if it is not invoked by any standard library routines and
if it is not declared in any standard header.

>Similarly, portable programs cannot really use these extensions,
>no matter how convenient they may be.

A portable program cannot rely on the existence of a vendor-specific
function such as "pnmatch", but only because it doesn't exist in some
environments -- no other reason.