string comparisons in C

[Richard E. Covert]

In article <10533 at smoke.BRL.MIL>, gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
> 
> 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.

	This is an interesting stream of messages about pnmatch(). I first
posted it because I thought that MWC had written a clever little piece of
code. I have found out that pnmatch() once existed in Version 7 (MINIX is
Version 7) UNIX.

	Anyway, the talk is now centering around portability issues. I have been
programming for quite a few years and I realize just how important portability
is, BUT, a good software engineer decides when portability is not an issue, 
and doesn't always stick to the book.

	My application involves operating system and hardware specific issues
which make my program non-portable to other non-GEM computers anyway. Possibly,
I could port my program to an IBM PC running DRI GEMDOS, but it wouldn't have
all of the different types of picture files that the ST does anyway. So, I
maintain that portability is a moot point in my application. Furthermore,
my application is non-portable due to the fact that AES/VDI headers are not included
in the ANSI Draft. And I have a copy of the ANSI Draft for C at my desk at work
and at home.

	I did look up pnmatch() and it is not in the ANSI Draft C. But neither is the 
regexp() function mentioned elsewhere.

	In any case, I made the decision to use pnmatch() because it fulfills
my need, and it is unlikely that I will ever need to port this program. Also,
and finally, if portability is an issue, then you can purchase the source code to
the Mark Williams C compiler directly from Mark Williams Corp for $149.00.
And then you can use pnmatch() to your heart's content!!

P.S. Try porting the ST fsel_input() to some other computer!!! And people are
worried about pnmatch() not being portable :-).

Richard (just trying to write some GEMs) Covert