For some years, I wrote most of my code in assembler, first on a CP\M system, and later, under MS-DOS. A friend introduced me to C just over a year ago, and I could kick myself for waiting so long to discover it. What used to take days in MASM can be written in hours (or minutes) with C, especially the input/output functions.

When I recently upgraded to QuickC v2.5, I returned the CUG membership card in the package, and began receiving the C Users Journal. I've enjoyed the magazine almost as much as I've enjoyed working with the language.

Your column and comments are always informative, and I appreciate the magazine's coverage of specific issues — C++, Liana, Windows, etc.

These articles are so useful because they represent real-world programming, where I might spend one evening coding a device controller, then spend three months coding the user interface (even in robotics and automation, they won't buy it unless it has pull-down menus and bells and whistles).

That brings me to my point.

A reader recently complained that C doesn't have a cls function. You answered that the ANSI committee was reluctant to set any standards of that type, because they insisted on viewing all input and output as streams.

That letter struck a chord with me. By being so fanatical about portability, and by insisting on viewing I/O from a single standpoint — that of streams — the ANSI committee may have ended up making the language less portable.

Simply put:

1. Few people will be impressed with and/or use (or more importantly, buy) a program that has a dumb-terminal display. Programs that scroll one line at a time are almost as exciting as watching mold grow.

2. Because the ANSI refused to specify standards for these basic display functions, the programmer is forced to sacrifice portability with the first clearscreen or locate cursor function.

Sure, I could write a very portable program that uses ANSI.SYS to control the screen. The problem is, it would run slower than itch, and no one would buy it. Now, I realize that setting a GUI standard might be beyond the scope of an ANSI committee. But after giving it a lot of thought, I believe that the current standard is too limited. More simply put: I respect ANSI's viewpoint, but in this day and age of 486 PCs and VGA monitors and Visual BASIC and MacIntoshes, can't I expect my programming language to have a standard function for wiping a screen or locating a text cursor?

A number of objections are commonly raised. The first one goes, "You're opening Pandora's box; where do we stop? Next, they'll want functions like SET_CIRCLE_COLOR ..."

I agree that you have to know where to stop. Graphics functions, in particular, might not be easily standardized. But couldn't we agree on a couple of functions that would at least bring C up to par with BASIC for text display?

My list would include cls, locate_cursor, and set_text_color. These could be implemented on virtually all modern computer systems.

The next objection would be that many computers don't support text positioning, color and/or graphics. So? If the computer won't support color, the system just ignores set_color and displays in monochrome text. If the computer won't support hardware functions such as moving the cursor, I'll just have to work around it.

That's precisely what I'm doing now, so what have I lost?

In closing, I don't want to criticize the ANSI committee unfairly. I respect what they've done, and agree that a standard was needed. All I'm saying is that they could have looked a bit more at the real world, rather than just at a theoretical stream concept, before setting that standard.

As computer hardware becomes more sophisticated, we're actually going to pay the price down the road in reduced portability, as programmers are increasingly forced to resort to their own — and quite non-ANSI — solutions to each user interface.

Yours truly,

Stephen M. Poole
122 N. Main Street
Raeford, NC 28376

You missed the point. We were not in love with a "theoretical stream concept" to the exclusion of all reason. Rather, we did nearly all our work at a time when streams were very real and screens were very new. It wasn't clear that your particular set of primitives were worth standardizing. Now the issues are more clear cut. You can still isolate the disturbance in a few system-dependent functions. Remember, portability is a statement about relative cost, not a true or false condition. — pjp

Dear CUJ:

Mr. Wilbon Davis' article on time complexity in the September 1992 issue was quite interesting.

However, it gave only a single sentence to a very serious problem concerning many quicksort implementations; that the use a fixed pivot point can result in O(n2) time, the same as a bubble sort. qsort's run time is very much probabilistic. There are a great many programmers who believe otherwise.

In the Febrary 1992 issue of Unix Review, Nr. John Bently explained the reason for this and showed that the problem is present in many of the popular qsort implementations. Since any fixed pivot will result in quadratic run time he suggests adding a bit of randomness to the pivot selection. The possibility of quadratic run time still exists, but only if the data to be sorted is in cahoots with the random number generator.

In the August 1992 issue of Unix Review. Mr. John Bently also examines the heapsort and its problems.

Sincerely,

Mr. Carey Bloodworth
1601 North Hills Blvd.
Van Bure, AR 72956

Your point is well taken. Quicksort can have nasty time complexity for some patterns of input. — pjp

Dear Sir/Madam:

I would like to know if you could help me with the following. I would like to create computer games and animation (musical animation). I have some programming background, and I have Borland's Turbo C++ and Assembler.

I have a 386SX IBM compatible (16 MHz) with a VGA monitor. I use v3.3 MS-DOS. I have 1 Meg of RAM, a 60 Meg hard drive (Drive C), two high density drives 5 1/4" (Drive A) and a 3 1/2" (Drive B), a 24 pin dot matrix printer (Roland Raven 2417), and use a keyboard for everything. I am presently upgrading to the following: MS-DOS 5.0; Windows 3.1; Soundblaster Pro; 10 Megs of RAM; 245 Meg hard drive; math co-processor; and a mouse.

I am considering at the end of this year looking into a 33 MHz or higher motherboard and next year a CD-ROM, but I am considering waiting a little longer for the CD-ROM as I want to read and write it and the ones available now are read only. I would like to create computer games like Conquest of Longbow, Wolfpack, Indiana Jones Last Crusade, Fate of Atlantis, Prince of Persia etc. I would like to create my games as life like as the ones mentioned.

I have a game in mind that deals with ancient Egypt. It needs to be able to create pictures such as pyramids, coffins, King Tut's gold mask, hieroglyphics, etc. I would also like to create animated films such as Walt Disney's Beauty and the Beast and 101 Dalmations, etc. What I want to do (if possible) is to create the animation, with the music from the CD-player, and record it on diskette. Once this done I would like to transfer it on a VCR tape and play it on my T. V. Can this be done?

Can you also provide me with the following:

1. Can you recommend books that show how to create games and animation? If so, please give title of book, author's name, and if possible where to purchase.

2. Call you recommend any schools that provide correspondence learning in this matter. Please give name and address.

For the programs listed in your magazine, can diskette with the programs already in the magazines be purchased. If so please provide cost, shipping and handling, and method of payment. Also can they be used with Borland's Turbo C++?

If you can kindly provide me with any other information that is not requested in this letter, please do so as I have written letters to schools here in Canada, magazines, and computer companies. But all say they cannot help me. Please understand that I would like very much to learn as I enjoy playing the games and am fascinated by them. I would really like to learn how I can create my own.

Thank you for your cooperation in this matter. Hope to hear from you soon.

Yours truly,

Victoria Ceolin
510 Acadia Drive
Hamilton, Ontario
Canada
L8W 3A4

You've laid out a very ambitious program. You have much to learn to get where you want to go. You'll also have to wait another year or two, as you've already guessed, for inexpensive hardware to come within reach of your dreams. But please don't stop dreaming. Your fascination with what can be done with computers can see you through the tough learning.

My recommendation is that you get one of the simpler animation programs currently available and start practicing your craft with it. Reading CUJ will help you learn whatever programming you may need, but I suspect you want to keep that to a minimum. Also read PC Magazine from time to time to keep track of the latest advances in PC hardware and software. Sorry I can't be more specific, but I encourage any readers who share your interests to contact you directly. Good luck. — pjp

Dear Dr. Plauger:

One of the few things more humbling than admitting to bugs in your carefully-crafted software is the introduction of new bugs when attempting to squash the old ones! Or, as Charlie Brown would say, ARRRRRRRRRRRGH! I am referring to your article in the September, 1992 issue of the C Users Journal, in which you attempt to fix a bug in which a failed memory allocation with malloc is ignored and data are copied to an address specified by a null pointer. (The code in question can be found on page 12.)

Either the replacement code has fallen victim to a typesetting error, or else it must not been successfully passed through a conforming C compiler. This is a very real risk that we expose ourselves to whenever a code change seems so trivial that we only test it with the C compiler located between our ears! Have you noticed the error, now that I've directed your attention to the code fragment?

Maybe it's true that the only time we can say with assurance that all the bugs are gone from a program is when the very last copy of the program in existence has been incinerated! I feel that this is true for most non-trivial programs I've written!

Yours truly,

John P. Toscano
PharmData Systems
P.O. Box 11537
St. Paul, MN 55111-0537

Error noted. It was indeed a transcription error. Thanks for reporting it. — pjp

Mr. Plauger,

I thoroughly enjoyed Dwayne Phillips's, "The Foundation of Neural Networks: The Adaline and Madaline" (September 1992). It very clearly presented the fundamentals of neural network programming.

I feel that a few small changes in the C code provided will yield improved performance. I am referring specifically to Listing 4, which makes the final AND/OR/MAJORITY decision. In the first two cases AND and OR), basic logical principles allow the for loops to be terminated immediately upon finding the first of the appropriate values. For example, in the AND decision, the loop may be terminated upon finding the first FALSE value (--1). There is no need to check any further inputs, as only one FALSE input is necessary to ensure a FALSE output in an AND condition. Similarly, the OR decision can be terminated as soon as the first TRUE value (1) is found. This is the same method used by C compilers to "short-circuit" logical tests. In both cases, inserting a break statement into the loop should do the trick. [Code available on monthly code disk.]

The MAJORITY decision code can also be improved by noting that the outputs being checked conveniently have the values 1 and --1. All that is necessary is to sum up all outputs. If the sum is positive, the 1 values are in the majority; if the sum is negative, the --1 values are in the majority. To be consistent with the original code, a sum of O should also yield a result of --1. Refer to the listing for the exact method.

Admittedly, with the small size of the networks presented in the article, the effects of these changes will probably be negligible. However, the performance improvement from these modifications could be important if this (or similar) code is used as the basis of larger, more complex networks.

Yours very truly,

Eric B. Schuyler
81 Yorktown Road
Snyder, NY 14226

Dear Dr. Plauger,

Thanks for your encouraging response to my earlier letter (CUJ Sep. 1992) concerning a proposed article on fail/fool-proof data input functions in C. At your request, I will expand a bit further on my suggestion. I see two aspects of the problem: input of individual data fields of various types, and combination of these fields in a data input screen.

Concerning the first aspect, an input function for a given data type, e.g. currency, date, string of limited length, and other specialized types, should validate input immediately during data entry and alert the operator on errors. It should also allow correction of mistakes made during entry.

Enclosed is an example of such a function for input of currency data that I wrote some time ago. It uses non-portable, unbuffered input functions, getch and putch, supported by Borland and Microsoft compilers, but not necessarily by others. Possibly, getchar could be made to work as well. Of more importance, I suspect that this function could be implemented more succinctly by a better programmer — hence my suggestion for the article!

As to the second aspect, a collection of data input functions should be combined in such a manner that the operator can return to an earlier data field to make last-minute corrections, e.g. through use of the PgUp and PgDn keys. This may be the easier of the two aspects, but is certainly not trivial.

After my letter appeared (the first time!) in the August issue of CUJ, I received a response from Robert A. Radcliffe (Philadelphia, PA), author of Data Handling Utilities in Microsoft C. Unfortunately, that text is now out of print, although the author still has some of the code disks. Maybe you could convince him to write the kind of article I have in mind!

Thanks for your interest,

W.F.H. Borman
209 Logwood Drive
Evansville, IN 47710
Tel: 812 464-5435

Dear Mr. Plauger:

I was much impressed by your mea culpa contained in the "Standard C: Bugs" column in the September, 1992 issue. It was a pleasure to find someone noble enough to admit mistakes can occur and that he, too, is a mere mortal. Unfortunately, character as fine as yours is a rare commodity!

I do think, however, that you were a little too hard on yourself. There is another certainty in life besides Death and Taxes for anyone who writes (or uses) software: bugs.

A bug in the vaunted Kernighan and Ritchie getline function on page 26 in the first edition and page 29 in the second edition of The C Programming Language causes the example to fail, as do dozens of other examples throughout both editions of "the book." They use getline expecting it to return 0 (zero) for a blank line when in fact it always returns 1 (one) or greater. The precedence table on page 49 of the first edition has errors in it. Borland's C compilers happily fopen files whose names have spaces in them (which of course can't be deleted by normal means). In Turbo C v2.0 and older versions, free failed if gets and related functions were used for keyboard input.

If the authors and all those people involved at Bell Labs and Prentice Hall couldn't get a 13-line function right after ten years and two editions, why should anyone expect you to write perfect software? A true cynic sees known bugs as job insurance!

If even the originators of such a great lean and mean language as C can't avoid a few bugs shouldn't one place simplicity and reliability at the top of one's priorities and always expect bugs? Ronnie R's favorite Russian proverb, "Trust but verify," should hang on every programmer's wall.

Kindest regards,

Elliott K. Rand
President, Keep It Simple Systems
P.O. Box 510093
Melbourne Beach, Florida 32951
(407) 729-0187

Thanks, I needed that. — pjp

Mr. Plauger,

Jodi Leonard informs me that you doubled the price for your C library code disk since it was "updated and expanded." Humpf! Other than fix bugs, what does "expanded" include?

I read your article describing the bugs found, it was somewhat amusing as a programmer's "confession", if not very scientific.... Care to expand in your next column what was changed? Does the current disk also come with a list of known bugs?

Thanks,

Mike MacFaden
Group Leader Unix NMS Development
Premisys Communications, Inc
1032 Elwell Court Suite 111 Palo Alto,
CA 94303
email: ...!fernwood!premisys!mike
mike@premisys.com
Compuserve: 72711.2060
voice: 415-940-4787
fax: 415-940-7713

The new code disk contains no bug list because I fixed all known bugs at the time I released it. I have since accumulated two (small) bug fixes, but I'm not about to thaw a frozen release whenever I find yet another bug. — pjp