From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.programming
Subject: Re: need a HINT on a C code parsing name-strings
Date: 6 Apr 92 06:50:48 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <92096.184215DECBC@CUNYVM.BITNET>, DECBC@CUNYVM.BITNET writes:
> I am writing a C code to parse an input string formatted in
> 'lastname,firstname,middle-initial' of each field is varying
> length and total length is 30 bytes, into three separate
> strings, 'lastname,' 'firstname,' and 'middle-initial.'
> 
> My code doesn't satisfy the efficiency required by my demanding
> boss. So, folks, I really appreciate it if u would give me some hints.

Um, that really is a rather culture-speficic format.  My father's name
is "John AEneas Byron O'Keefe".  (The AE is one letter.)  How do you
fit that into your format?  How about one of my students, "Luong Nga"?
How about that well-known Computer Scientist "J Strother Moore", who
has endless trouble with people mangling his first name (it's a letter
J, no more, no less)?  How about "Jan van de Wettering"?  How, God save
the mark, about a name like "Geoffroy Amadeus Rassmussen-McPherson" (which
is 37 characters)?

Why is your boss worrying about the efficiency of your code when she
should be concentrating on FIRING the dolt (I'm being euphemistic here)
for came up with such a ludicrous input format in the first place?
The simplest way to handle names is as unanalysed strings, so that if
someone wants to have a comma in their name (I kid you not, that HAS
happened) as if it were a letter, nothing goes wrong.  The next simplest
is to let the human being using the name specify which part is the sort
key, so that it's "SortKey,Rest of Name".

I am fed up to the back teeth with *idiot* computer programs and/or
incompetent data entry clerks who can't handle my name right.  My
name is "Richard Anthony O'Keefe", and it abbreviates as "R.A.O'Keefe".
I am tired of being called RA.  (If I _were_ the god of the sun I might
be pleased, but I'm not.)  I am _greatly_ inconvenienced when a bank
files some of the information about my accounts under "O'Keefe" and
the rest of it under "OKEEFE" and their ##### programs think those are
two different people.

Why isn't your boss telling you "Study up the new wide-character type
in ANSI C and the functions that deal with strings of multibyte characters
so that we'll be ready to support Japanese/Arabic/Greek/... names as soon
as our operating system and terminals are ready?"

Assume that the input format is
	char buffer[31];		/* NUL-terminated string */

Let's declare some more variables.
	char *family, *personal, *initial, *temp;
	int family_len, personal_len, initial_len;
	const char comma = ',';

	family = buffer;
	temp = strchr(family, comma);
	assert(temp != NULL);		/* check your input! */
	family_len = temp-family;
	personal = temp+1;
	temp = strchr(personal, comma);
	assert(temp != NULL);		/* check your input! */
	personal_len = temp-personal;
	initial = temp+1;
	assert(isalpha(initial[0]) && !isalpha(initial[1]));
	initial_len = 1;

If this is inefficient, blame the compiler.  Some machines can do
strchr() very fast indeed.

Change the assert() calls so that the program apologises profusely
for its ethnocentrism and incapability when someone's perfectly ordinary
name doesn't fit into the Procrustean bed of your input format.  Make it
clear that the data is ok but the design is a crock of XXXX.

Then you should start worrying, and I really do mean worrying to the point
of feeling ill about it, about alphabetic case.  Some data entry clerks
have been brainwashed by generations of cheap-and-nasty terminals into
thinking that computers only like capital letters.  Some data entry clerks
have figured out why there is a shift key.  So sometimes you are going to
get names in capitals and sometimes you're not.  Worry about letters that
haven't got an upper case equivalent.  (They exist!)  Worry about blanks.

-- 
I am writing a book on debugging aimed at 1st & 2nd year CS students using
C/Modula/Pascal-like languages.  Please send suggestions (other than "you
_must_ cite "C Traps and Pitfalls") to ok@goanna.cs.rmit.oz.au
Newsgroups: comp.programming