Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utastro.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!eagle!harpo!seismo!ut-sally!utastro!nather
From: nather@utastro.UUCP (Ed Nather)
Newsgroups: net.lang.c
Subject: Re: What Can't C Do? (strings)
Message-ID: <58@utastro.UUCP>
Date: Sun, 18-Mar-84 22:29:30 EST
Article-I.D.: utastro.58
Posted: Sun Mar 18 22:29:30 1984
Date-Received: Tue, 20-Mar-84 00:38:21 EST
References: <6900@unc.UUCP>, <226@opus.UUCP>
Organization: UTexas Astronomy Dept., Austin, Texas
Lines: 27

<>
Discussions of string comparison usually start with two assumptions
that I believe are false:

	1. A language is deficient if it lacks string comparisons;
	2. They *could* be included, at modest cost in complexity.

In the various C programs I have written that involve string comparisons,
I find the ability to call a function to do exactly the right thing a
real convenience.  Sometimes I want to compare a substring to a string
both of which are null-terminated; next time the substring may not be.
Sometimes I want the pointer updated to point to the first character
that didn't compare, sometimes not.  I may want the *second* appearance
of a substring rather than the first or last.  

If every possible option were included as part of a language the cost in
complexity would not be modest -- and I'd never remember all the options.
Alternatively, if only the basic, vanilla comparisons are included, it
won't do what I want, I'll have to write a function call anyway, then
explain in a comment why I had to do it that way, fuming all the while.

After all this, an opinion:  Leave the string comparisons OUT.
-- 

                                       Ed Nather
                                       ihnp4!{ut-sally,kpno}!utastro!nather
                                       Astronomy Dept., U. of Texas, Austin