Xref: utzoo comp.sys.atari.st:17756 comp.lang.c:19922
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!bloom-beacon!adam.pika.mit.edu!scs
From: scs@adam.pika.mit.edu (Steve Summit)
Newsgroups: comp.sys.atari.st,comp.lang.c
Subject: Re: string comparisons in C
Keywords: C, atari st, mark williams
Message-ID: <12689@bloom-beacon.MIT.EDU>
Date: 15 Jul 89 02:26:12 GMT
References: <44672745.14a1f@gtephx.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 21

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."  Vendors are
not supposed to pollute the namespace with "convenient" (but
invariably unportable and system-specific) routines.  ("Then why
do so may vendors do so?" you ask.)  Vendor-supplied routines not
mentioned in the standard are supposed to have names beginning
with at least one underscore (e.g. "_pnmatch").

Similarly, portable programs cannot really use these extensions,
no matter how convenient they may be.  When extensions are used,
they should be hidden behind at least one function call; that is,
don't call pnmatch directly, but rather invent your own routine --
"match_filenames" or something, which calls pnmatch.  Then, when
you port your code to a different system that doesn't have
pnmatch or uses some wildly different wildcard mechanism, you
only have to rewrite match_filenames().

                                            Steve Summit
                                            scs@adam.pika.mit.edu