Dear editor:

As always, I read with great interest your editorial in the May 1992 issue of the C Users Journal. I would like to accept your invitation in that editorial to suggest a topic for a future article.

Several times a year I teach an introductory class in programming in C at the local state university. In addition to discussing the syntax of C, I always stress the need to make programs user friendly as well as fool- and fail-proof.

Since every introductory text in C programming starts of by teaching the use of scanf for user input, it never takes long before I find myself apologizing for the existence of such a misbegotten function which offers more opportunities for crashing a program than any other I am aware of.

Of course, scanf has the charm of being a quick and dirty input function which is excellently suited for short and simple demo programs that are useful in a classroom setting. Still, after telling the students to stay away from scanf in real life, the question remains, what else is there?

Combinations of gets or fgets with sscanf or atoi/atof are a way out, but still don't yield the safety and protection that a well-written program should provide.

I have written some short routines in the past for error-proof currency input and such, but I am not confident that those routines are as complete and straightforward as they could be. In the years I have been reading CUJ I don't remember seeing an article on the topic of reliable input procedures. I believe that many others, in addition to myself, would be interested in such an article. Would you consider this topic for a future issue?

Sincerely,

W.F.H. Borman
209 Logwood Drive
Evansville, IN 47710

Sounds like a good prospect to me — send us a more detailed outline. You should know that scanf had few supporters within X3J11. We left it in because it was there. Perhaps the exception-handling machinery in C++ will give X3J16 an excuse to make scanf more useful, but don't count on it. — pjp

Gentlemen,

Professor Owen Gailar, in his letter published in the April CUJ, laments the fact that Borland's Turbo C does not provide easy access to user supplied libraries through the Integrated Development Environment (IDE), and he is certainly correct in his condemnation of the clumsy method required using a project file.

Interestingly enough, Turbo C Version 1.0 allowed you to do the very thing that he has been searching for, and the capability was removed in Version 1.5! You could specify a complete library name in the IDE Library Directory selection, as well as the path to the default libraries, and the linker would cheerfully link in the specified library as well as the default libraries! That is, you could set up a linker path in the IDE that read like this (as mine did): d:\tc\pdfcs. lib;d: \tc\.

Long, long ago I suggested to Borland (on their CompuServe forum) that this capability be restored; after all, who wants to set up a project file for every last thing they compile? Perhaps if enough people request it they may reconsider.

Regards,

Patrick D. Farrell
4141 Sylvia Court
Shorcveiw, MN 55126

Sounds good to me. — pjp

Dear folks,

This letter is directed to those Master Programmers who either believe they have successfully met every conceivable challenge, or that they can. I have one for you. I'll bet a steak dinner that no one in the world has or can do this one within the next six months. First one to successfully respond to my satisfaction gets the steak dinner — there'll only be one of those! But there may be alternate prizes for subsequent responses.

The challenge is Japanese patents; more specifically, putting a U.S. patent in a form such that it can be filed in the Japanese patent office in Tokyo with reasonable hope of acceptance. It seems they still insist on the use of Japanese language characters, even though many technical terms are simply direct phonetic translations into katakana or hiragana characters. Maybe someday they'll get around to permitting filings in English; until then, non-Japanese inventors are stuck with some very unpleasant facts: Either learn Japanese or use an expensive law firm if you want to have coverage in Japan. Those facts tend to shut out everyone but large corporations.

Proposed solution: A computer program that will translate from a U.S. patent on disk to produce a Japanese patent application on disk. I understand that Tokyo does allow patent applications to be on floppy disk, as long as they are in proper format and in the Japanese language. The format itself does not appear to be much different from ours.

There are some formidable problems, such as accommodating the double-byte kanji characters, for example. Another is language syntax. Hey, if it requires a super-computer, just say so; but I may ask for proof!

Partial or alternate solutions will be considered. Any takers?

Sincerely,

Homer B. Tilton
8401 Desert Steppes Dr.
Tucson, AZ 85710

Dear Mr. (Dr.) Plauger,

For all practical purposes I subscribe to The C Users Journal and Computer Language just to read your commentary on the state of the computer world. I especially enjoyed "all I want to do is..." and earlier stories about physics, physicists, and computer programming. Thank you for sharing your world with me.

The other reason for this letter is the hope that you might have knowledge of a reference where digital simulation of analog computers is treated; preferably in C but I understand FORTRAN is more likely.

Thanks you again,

Wil Schuemann
705 Wagner Dr.
Carson City, NV 89703

PJP replies: Golly! I saw an ad just a week or so ago for the very thing you're looking for. But I can't remember where I saw it. Try the back pages of Physics Today or Computers in Physics. Can anybody else help out? And thanks for the kind words. — pjp

Dear Mr. Plauger,

I wonder if you could help me with the following problem.

I want to read ASCII files produced on a Mac from a DOS-based IBM PC compatible, of course, having a 3-1/2" drive. Have you any idea how to solve it?

Yours sincerely,

Prof. M.A. Pollatschek
Israel Institute of Technology
Technion City, Haifa 32000
Israel

Because Mac disk controllers use a different low level encoding scheme, there is no software-only solution to this problem. You can, however, get an add-in board and supporting software for your MS-DOS machine that will allow you to read and write Mac disks. We use Matchmaker, a product from Micro-Solutions (132 W. Lincoln Hwy., DeKalb, IL 60115, (815) 756-3411), to read and write Mac disks. Since this is the only such product with which I am familiar, I can't comment on it's merits relative to possible competitors. — rlw

Dear Sir/Madam:

I find your journal useful, both in terms of the articles I do read and the range of topics that are of secondary interest to me at the current time. These provide ideas that I can relate to my current projects. In that vein, do you have or have you considered producing an index of articles, preferably with abstract and/or key words either in paper or electronic form? I may have missed it in one of the past issues.

Secondly, I am looking for a "super calculator." Specifically it will take a string consisting of numbers, arithmetic symbols (e.g. * — + /) and parenthesis returning a real value or an error flag. This is exactly like the calculator used as an example in lex & yacc by Mason and Brown. The twist is that we also want to include variables and functions within the string. I think that the variables could be handled by a look-up table with the variable name and the address of the variable. The functions could be handled by a table with names and addresses as well. Function parameters could be passed using the same type of calling convention used in main(int argc, char ** argv)), so the called function could then do atoi or atof or use string arguments as appropriate. If you have any suggestions of where I can find, buy, or read about this type of capability, I would be most grateful.

Sincerely yours,

Gregory Diehl
Director of Product Engineering
128 Wheeler Road
Burlington, MA 01303

The UNIX utility bc does much of what you want. Does anyone know of a version more widely accessible? — pjp

Dear Mr. Plauger,

For about two years, I have enjoyed reading your column in CUJ. It provides a lot of insight into the darker corners of C.

A few days ago I got a copy of your latest book Standard C Library. I scanned through the chapters of math functions and locales, but before I said "now let's look how the experts code," I was disapointed.

There is a general flaw (in my opinion) in your examples: you never take into consideration that a NULL-pointer may be passed as an argument to a function. In the MS/DOS-world it seldom matters, read-access by a NULL-pointer gives 0 or random values, write-access may crash the system (much later...). But in a protected-mode OS (like QNX), in the right memory model, NULL-pointer references cause a processor memory exception.

We make much use of assert to check incoming values in functions. It's a matter of philosophy, whether a function like strcpy should stop execution with an assert-message or whether it should check for NULL-pointer and do nothing.

But in my opinion it is the worst to simply ignore this and go to the gigo-standpoint (garbage in, garbage out), especially when it is a reference-book like yours. (By the way: is a NULL-pointer instead of a mode string in fopen garbage? Your excerpts from the standard are quite quiet on this)

Please consider inserting assert-statements for all parameters (which are not checked otherwise). It would be a hint to the reader/implementor "this code works only under this precondition..." Then the reader may decide how to take care of this.

Sincerely

Dieter v. Holten
Konigsreihe 30
D 2000 Hamburg 70
Germany

The C Standard explicitly states that you cannot call library functions with null pointers, unless a given function explicitly defines the effect of such an argument. I know it's safer coding practice to check for nonsense arguments, but users of libraries often disagree. They often prefer the utmost in performance to the utmost in safety. For what it's worth, I coded the library this way intentionally, not as an oversight. — pjp

William Smith:

Much as I appreciated the appearance of your article in C Users Journal, I disagree with several of the conclusions.

The point you make about the possibility of using a lot of processing time in copying data is well taken. With partial pivoting, however, the number of copy operations is of lower order than the number of floating-point operations, even if all of the data are interchanged "FORTRAN-style." For large matrices (order 50 or more), the time spent interchanging should be relatively small if the compiler generates efficient code. Compiler writers have paid more attention to this in the last year or so. For example, compilers which use the Kuck Associates preprocessor will substitute calls to special library subroutines to speed up vector-data copy.

The difference in speed between your "FORTRAN-style" C code and your hand-optimized version must come from elimination of indirection from the inner loops. This may, in fact, be a big deal, if pointers are complicated as on the Intel architecture, or if the failure to eliminate indirection inhibits pipelining. This problem does not necessarily arise in FORTRAN, because of FORTRAN's simpler storage scheme for multiple-dimensioned arrays. The definition of FORTRAN eliminates any possibility that the rows may overlap in a correctly-written program, while a cautious C compiler must allow for such a possibility or perform a global analysis on the whole program.

Perhaps your point should be restated. Just as certain commercial libraries have poor performance because they were originally written in Algol and not optimized for the current compiler language, uncritical translation from FORTRAN to C can inhibit performance. The C compiler tradition places more burden on the programmer to avoid situations which depend on the compiler to optimize generated code.

Sincerely yours,

Dr. Timothy C. Prince
Consulting Design Engineer
Solar Turbines MS C5
PO Box 85376
San Diego, CA 92186-5376

William Smith responds:

Thank you for your comments. The difference in speed between the FORTRAN style C and the optimized C is mainly due to the replacement of many individual element exchanges with a single pointer exchange. This reduces the amount of physical memory that must be copied. As the matrix size increases this difference is significant. I have found that I can not count on a compiler to do this optimization. Elimination of indirection is a minor optimization compared to the elimination of element exchange operations. I try to depend more on the optimizer between my ears than the optimization capabilities of the particular compiler I happen to be using. The article was meant to inspire and encourage the use of C specific language features when translating to or improving numerical analysis code in C.