I am pleased to see more interest in floating-point applications in the letters published in the April issue. I must apologize to Mr. Taylor if I didn't make it clear that I was suggesting the use of double as a 53-bit integer for monetary calculations partly because 32 bits could easily be insufficient, but also because, on modern systems, it allows satisfactory control over rounding of fractional cents. Several people have pointed out the floor(x+. 5) solution for rounding, which is satisfactory when you are not concerned about speed or the mis-matched treatment of positive and nagative multiples of 0.5.

Getting on to a more interesting subject, I wish Mr. Rudin well in his publishing endeavor, and I expect he has plenty of valuable material. On the other hand, I find it outrageous to criticize the authors of Numerical Recipes for putting clarity and reliability ahead of efficiency in their published code.

If Mr. Rudin compares the FORTRAN and C editions, he will see that they made a sincere effort to clarify the code in the C edition. I, for one, feel that they made a great stride forward in eliminating programming style which caters to the weaknesses of the systems of a particular era, instead concentrating on the basic requirements of the job. At the time their book came out, I thought it might be a mistake to ignore the fact that most C compilers required local variables to be declared register double for efficiency. Since that time, enough compilers have appeared with excellent register allocation to more than justify this omission.

Mr. Rudin castigates us for writing code which relies on the compiler to perform strength reduction in inner loops. I tried the Listing 3 code on several levels of Sun C, operating system 4.x, both Sun 3 and Sun 4, and found that all of them were able to remove the integer multiply from the inner loop and create their own local pointers. If this were not so, the SPARC architecture, which has no integer multiply, would not be viable as a C platform. The GNU C compiler, version 1.37.1, does not perform strength reduction on these multiplications, but I'm sure that some future version will.

There is no measurable difference between the speed of Listing 3 and Listing 4 under these compilers, at least when the sum is accumulated in a local non-volatile variable. That is not a question of FORTRAN vs. C style; it has always been good style in either language to use local variables when appropriate, both for efficiency and to avoid side effects. With any good optimizing compiler, the programmer is and should be free to write this code in the way which is most legible and secure. Why compromise published code to fit the limitations of current and past systems, when there is ample proof that these limitations can be removed?

Along with Mr. Rudin, I have played with the FFT and quicksort algorithms from Numerical Recipes and found more efficient versions, more so in FORTRAN than in C. The loading of the dice against quicksort was already present in the FORTRAN version, which, however, is considerably better than some versions which I have seen published by eminent authorities.

Never say always. If you are writing code for the 68000 family, a loop control of the form

short j=n-l;
do{ ... }
while( j-- != 0 )
   /* or while( --j != -1 ) */

I seem to recall authors with more experience than I stating that for or while are to be preferred over do{}while when both will do the job. I mention this only to point out again that the lack of a REPEAT..UNTIL in standard FORTRAN (there is a DO...IF() EXIT; ENDDO in FORTRAN 90) is not an issue over which I would discard the best textbook in its category.

Finally, I would like to point out that the marked similarity between the Numerical Recipes codes in the FORTRAN, Pascal, and C has enabled the authors to take advantage of years of practical experience and debugging which are not matched in any comparable collection.

Sincerely yours,

Tim Prince
39 Harbor Hill Rd.
Grosse Pte Farms, MI 48236

Dear Bill,

I am near to completing a product for the C marketplace and hope you can direct me toward a software publisher. As background, I have a Ph.D. in Computing and about 30 years experience in computing. I grew up in Cronulla, about 15 miles down the coast from where you are living. During summer in the 50's, I spent most of my time in the surf.

In 1986-87 I built a trace system for the MIX C compiler down in Dallas, Texas. This trace was written in assembler code for the IBM PC, and relied on information generated by the C compiler. This system has been well received and is still selling well.

Last year I started thinking about building a next step in the visualization techniques I have been developing. Briefly, I think it is valuable to show a programmer as much as possible about the program he is running. A fully instrumented system is another description.

After looking for a C compiler maker who would generate the information that I need, I decided I would be better off to build an interpreter for the C language myself and add all the trace behavior into one system. With control over the entire system, I am also able to include a browser. Overall, the system will be able to tell the user anything he wants to know about the program as static source or a running program.

The bias of such a system is toward giving the user information about his program, rather than toward high speed execution. Since a lack of execution speed can be an embarrassment, I have included a P-code generator so that the first time an expression is seen, it is parsed and a much faster form built. The next time that expression is seen, it can be evaluated much more quickly. Using this technique, I am running at speeds of over 1000 stats/sec on my 386/25Mhz.

This interpreter is itself written in ANSI standard C and implements ANSI standard C. I have about 24,000 lines of C code working and I estimate the final size of the product at about 30,000 lines. Proof-of-concept wise it is more than 80% completed, exhaustive-testing wise it is less than 80% completed. I am building it under DOS 3.3 using MS C 5.1 and writing directly to the screen rather than using any windowing scheme. [This code is well isolated!]

Because it is written in C, my system needs a fast computer and lots of memory space. I feel that problem will become less important with time. Because it is written in C with a view to being as portable as possible, I am hopeful that it will be applicable to a large range of platforms. The basic techniques I am building will be applicable to other languages such as Pascal and Algol. The obvious future target will be C++, but I will be content to handle C for the moment.

One of the new features I am adding is a visualization of the reduction of expressions. The user can see exactly how any expression is broken down, and also the value and type of any operand at any stage in the reduction of the expression. Another is to show the interpretation of macros and defines during the initial scanning of the source code.

I am not intending to compete head to head with C compilers biased towards speed of execution. I feel a product which shows a user full information about his C program fills a need.

I estimate I will have my system completed in about a month. I am looking for a small software publisher who is capable of taking my product, testing it properly and porting it to many forms. Please let me know if you can direct me towards such a publisher. Please feel free to make use of any information in this letter.

(Dr.) Neil Bennett
19916 190th Ave N.E.
Woodinville, WA 98072

You took a major step toward finding a publisher by writing this letter. A significant fraction of the commercial C community watches this space. I have already passed your letter on to one interested party. Good luck.— pjp

Dear Editors:

In his letter in the April 1991, issue, Volume 9, Number 4, Morton Rudin made an error in his macro for computing the square of a number. (quoted from Mr. Rudin)

#define SQR(x) (((z=x)) * (z))

Mr. Rudin has confused precedence and order of evaluation. Every C compiler I have used has always enforced precedence, but the order of evaluation is entirely up to the compiler, with the exception of certain operations. This renders Mr. Rudin's macro incorrect, as it is entirely possible and permissible to evaluate (z) prior to the evaluation of (z=x), provided that the result is consistent with the mathematical precedence induced by the parentheses. To force the computation of (z=x) to happen first, the macro should be:

#define SQR(x) (z=(x), z*z)

Perhaps you should cover the distinction between precedence and order of evaluation in more depth in one of your columns.

Sincerely yours,

Lew Bloch
P.O. Box 407
Bel Air, MD 21014

I already did. See "Grouping," Standard C, CUJ Sep./Oct. 1988. Thanks for the correction. — pjp

Dear C Users Journal,

I am in charge of software development at Cambridge Medical and read your journal eagerly each month. One reason for doing this is to identify possible "software components" and read reviews on them. Following the User Report on the C Communications Toolkit in the April 1991 issue, I felt that a report of our experiences was in order.

I am a software engineer, but as an engineering profession, we are still in the stage of infancy. To refer to the state of a more mature discipline: when my electronic engineering colleagues do a design, it involves a lot of selection of components from lists provided by their manufacturers (with second sources, of course). They do design at a high level of abstraction, and generally have to do detailed (gate-level) design for a small portion of the "glue" logic. This is not true for us. Most of my design is at the lowest levels of abstraction.

Our product is an ECG instrument, 68000 uP programmed in Whitesmiths C. The operating system kernel is CEXEC from JMI Associates. When we wanted to add serial communications to this, being good engineers, we shopped around for a software component which would reduce the development time. From the pages of your magazine, we identified and bought the C communications toolkit version 1.00B. An investigation of the sources suggested that the toolkit was of sufficient quality and modularity to survive the port to a different environment.

A software engineer then proceeded with the port. It took him about three months to get file transfer working to and from a PC. During this time a number of problems were identified. Three general problems (e.g., files left open after transfer) and 12 specific problems were encountered (e.g. Kermit Receive can miss every other byte in some circumstances). Work-arounds or fixes were found for about half of these. We reported these problems to Magna Carta, and received an updated version (v1.01) a little while later. Then, for non-technical reasons, the project was abandoned.

My complaint is that we were originally provided with a package which I would describe as "Not fit for the purpose", a term used in English law — the trades descriptions act. This experience with the C communications toolkit is not unique. I have had similar experiences with packages for: operating system; terminal user I/O management, graphics terminal/printer output, DOS disc structure I/O.

I am generally disappointed by the quality of software components. They generally entail more work to use than originally expected. Following their use, we have occasionally remarked that it would have been quicker to start from scratch and do the whole thing ourselves.

Two pleas. Firstly, can we have more of the "lower level of abstraction" of software packages, i.e., components at the function level. Secondly, the profession has to tackle the quality issues. Is there some independent (or user) metric of quality which could be made available prior to selection of a package?

Finally, this is not intended as a specific criticism of Magna Carta. They did respond promptly and courteously to our observations and sent an updated package (subject to trans-Atlantic postal delays). I have no indication that the current version of the package has not fixed all of the problems reported. The project was cancelled before this could be determined. As a software engineer, I would encourage them to continue providing software components, but to look to the degree of validation testing they do before releasing a product.

Adrian P Stephens, M.A., Ph.D.
Principal Software Engineer
Cambridge Medical Equipments Ltd.
50 Clifton Road
Cambridge CB1 4FJ
UK

I'm glad you didn't get around to your gripe list for the C compiler, since I wrote that one. Generally, I agree with your analogy to circuit design and with your assessment of the current state of the software art. I have two observations, however:

Mixing pieces of programs is far more complex than mixing electronic components. A closer analogy is requiring that a chip be composed of RTL, ECL, and CMOS technologies because you licensed masks from three different vendors. The software components business has made enormous strides in the last few years in improving interoperability. But we still have a long way to go.

Good software designers now know to design as much as possible with higher-level components such as spreadsheet packages, commercial operating systems, etc., rather than build everything from the ground up. That's where the great strides in productivity, and predictability, are coming in.

Even after the revolution, however, I can't see how to assign a simple figure of merit to most software packages. A DBMS is somewhat more complex than a resistor. We can expect to rely on product reviews and user reports for some time to come. — pjp

Dear Mr. Plauger,

I am a relative newcomer to the C language despite 20-plus years programming experience. Until 10 years ago, I programmed mainly in the assembler language of whichever machine I was working on at the time. After that it was mainly Pascal.

Pascal had its advantages from a production speed point of view but I always felt I was fighting it to make it do the things I wanted. With C, that is still sometimes the case, but not nearly so much. I like the way pointers are implemented, especially pointers to functions. I also like having void and casting. I don't like the way huge chunks of the library get dragged in for relatively minor function calls, but perhaps that is the implementation.

I wrote a Mandelbrot program in Turbo Pascal v5.5 and later converted it to Turbo C++. The Turbo Pascal version produced an .EXE file that was considerably smaller and, partly because of the way floating point is emulated, faster to run. C has many other advantages, however. I tend to use Turbo Pascal for fun programming and C for the serious stuff.

I've started learning C++, but the next project is urgent (again!) so I won't be using it yet awhile.

Now to get to the point. I love your "Standard C" articles. They give me just the sort of background information I need to understand why C developed the way it did. I've bought your Standard C book, but was a bit disappointed that it didn't contain the same historical stuff. I know it is only supposed to be a Quick Reference, and that is how I use it. I only found out about The C Users Journal recently, and have, of course, become a subscriber. How can I get hold of copies of all your earlier "Standard C" articles without having to buy the last however many years worth of the magazine or getting offprints at $5 a shot?

If you are going to publish the articles in a book, then I will buy it. Otherwise, could you quote me, including airmail to Australia, on copies of all your "Standard C" articles up to and including March 1991? I have received my first subscription copy for April 1991.

My favorite other sections in the three copies of the Journal I've seen so far are "Puzzles" by Rex Jaeschke and "Questions and Answers" by Ken Pugh. Please keep up the good work.

Yours Sincerely,

Len Baker
486 Whitehorse Road
Surrey Hills, Vic. 3127
Australia

You make a wonderful "straight man." I have just finished writing my latest opus. It is called The Standard C Library, and it contains quite a lot of the history you seem to like. Some of the material, in fact, is from past articles I wrote for CUJ. The book also contains a complete implementation of the Standard C library for those who love to study code or tinker with it. I have all my past articles in machine-readable form. Contact me at UNSW in Sydney or local e-mail at pjp@wsa.oz if you want to explore ways to get back copies. — pjp

Dear Mr. Plauger:

John Forkosh's article ("More Accurate Linear Interpolation," May 1991) is an interesting one. Obviously, he was driven by the need for blinding speed in function evaluation of only low or moderate accuracy. Such a concern is common in scientific computing and in computer graphics.

There are several improvements that can be made in such an algorithm, and there is one concern that needs to be expressed about accuracy. Least-squares curve fitting, as John used, suffers from the difficulty that it is impossible to estimate the error in the approximating function without a massive point-by-point search to compare the approximation with the original function. Numerical analysts prefer to use a Chebyshev or minimax type of approximation because the error bound is known and the error is what is sometimes called "equal ripple," or is as uniformly distributed across the interval of approximation as is possible. More about this later.

One improvemnt in the method is to remove the requirement that the straight line approximation be continuous, i.e., that the straight line segments cross at the xi. Seldom is this more than a cosmetic requirement or one intended in some mysterious way to placate Mother Nature (why not require that the slopes also be continuous at the xi?). If a numerical procedure is sensitive to discontinuities in the function, it is very likely to object to discontinuities in solving a huge set of simultaneous linear equations is also removed. The determination of the constants now becomes a matter of solving a large number (the number of intervals) of 2 x 2 equations which can be "presolved" by formula. An added bonus is that the constraint removal will actually improve the accuracy of the approximation! Each line segment now is optimized over its own interval without being forced to compromise with all of its neighbors.

Another improvement, contingent upon removing the constraint mentioned above, is to replace the least squares fit by a Chebyshev economization or minimax fit. Both of these are standard methods. Chebyshev is slightly less accurate, but is often good enough. A FORTRAN programmer for Chebyshev economization can be found in Carnahan, Luther and Wilkes [1], and a Pascal procedure (Remes algorithm) for producing a minimax fit can be found in Hultquist [2].

Finally, equation "a," as it stands, involves three addition/subtraction operations and three multiplication/division operations. For two multiplications and two additions, one can evaluate a quadratic polynomial

(a[i]*x + b[i])*x + c[i]

Yours Sincerely,

Paul F. Hultquist
Professor Emeritus of Electrical
Engineering and Computer Science
University of Colorado at Denver
6803 North 68th Plaza
Omaha, NE 68152

References:

1. Applied Numerical Methods, B. Carnahan, H. A. Luther, J. O. Wilkes, John Wiley and Sons, Inc., 1969.

2. Numerical Methods for Engineers and Computer Scientists, P. F. Hultquist, Benjamin/Cummings, 1988.

Numerical analysis seems to be a bottomless pit. Thanks for shining the light a bit deeper. — pip

Dear CUJ,

I am a new subsciber of your wonderful magazine and wanted to tell you that I thoroughly enjoy every issue I receive. I am fairly new to programming, a college sophomore CS major, and learn something new and useful in each and every issue. I especially enjoyed the articles by Art Shipman on multiple char array allocation and the string comparison article by Hans Zwakenburg. I just have two comments about the second article. First, I really liked the use of #define DEBUG to run the program as standalone and remove the definition for use as a function. Very creative. Second, this question will seem very novice, but that's what I am, so I will ask it. What is the benefit of using a comparison algorithm like Levenstein's rather than a conversion of the strings to uppercase or lowercase and a strcmp or strncmp call? I'm sure this is very obvious to professional programmers, but I'm lost. Thank you for your wonderful magazine. I dutifully await the next issue.

Sincerely,

Andrew Tucker
Seattle Pacific University
SUB Box 2241
Seattle, WA 98119

Sometimes an exact comparison misses the point. — pjp

Dear Editor:

I've been kicking around the MS/DOS environment for several years now, hoping someday to learn enough about C to write a few small applications. The only language experience I have is with dBase, where I'm able to write very tight programs, if not elegant applications.

How does one learn C? Put another way, can I learn C without learning Basic or Pascal? How much do I have to learn about the architecture of the machine — and should I learn about the machine with C, assembler, or a good book on the operating system (DOS)?

I doubt I'll ever have time to take classes, so I'd like to teach myself. C isn't dBase, but then C ain't assembler either. The question is what method is best. I subscribe to CUJ because, like anything else, reading good code is important. Somewhere between learning syntax, data types, etc. and allocating memory in protected mode (which I don't plan to do soon), there's a way to teach C without learning another language (right?!).

I plan to go with Borland, and I bought a few C books by the Waite Group and others. I'd love to get a C code generator like Pro-C, but I'm afraid it might be a waste — and my wife would torch my computer if I did anyway, 800 cruiser on top of the 350 for Borland C++!

Thanks for whatever guidance you may provide.

Sincerely,

Glenn White
4308 28th Place #28
Mt. Rainier, MD 20712

Sounds like you're off to a good start. There are oodles of books that endeavor to teach C at various levels. Find one that you like, then practice, practice, practice. — pjp

Dear Mr. Plauger,

I have recently begun reading The C Users Journal and have found it very useful. I have one question, though. Is the code displayed with various articles available from some on-line source for downloading?

It would be nice if this were the case, since many of us would prefer not to type things in from a magazine when trying new algorithms.

Other than this one question I do think CUJ is quite a good publication and intend to continue using it.

Scott Hopson

76207. 674@compuserve. com

The source for each issue is available on diskette from R&D Publications. We are still investigating on-line options. Thanks for writing. — rlw

Dear Mr. Percy:

I have just read your letter in the May 1991 issue of The C Users Journal. I'm sorry that you feel you were "subjected to" my article on large arrays, and that you questioned renewing your subscription as a result.

I, too, am always reluctant to attribute a problem to a compiler bug, since (like all programmers) I have learned over the years that the great majority of program problems are self-inflicted. Now and then, however, when I cannot find any relevant documentation, and the code's behavior seems to contradict everything I have read, I am forced to consider certain instances of behavior to be bugs.

Even if the "bug" turns out to be a documented feature, however, the user is still forced to deal with it, to get around it in some way. That was what my article was intended to do — to help other users use large arrays without running into the same obstacles that I did. You seem to be a knowledgeable C user, able to avoid certain mistakes without the need for an article such as mine. Your compiler also seems to provide more helpful messages than mine, and perhaps your documentation is also better; I can only report what I know. The responses I've received, however, indicate that there are a few grateful readers out there whose C expertise is (even) less than mine, who found the article useful, and who look forward to seeing other articles in The C Users Journal that they can understand and put to practical use. I learned something from your letter and hope you will consider contributing an article some day.

Incidentally, I use Turbo C regularly and consider it an excellent product — in fact, I used the word "excellent" in the draft I submitted, but it was edited out. However, lately I have compiled problem programs with Power C as well, and have found the second opinion it provides to be very helpful in eliminating bugs which go unreported in Turbo C.

Sincerely,

Stuart T. Baird
927 Parkview Drive F-301
King of Prussia, PA 19406

Dear Dr. Plauger,

I would like to let you know how much I appreciated Greg Chursenoff's article on serial communications in the April 1991 issue. I had been unsuccessfully attempting to write an interrupt routine to handle pulses from an anemometer for an AT-based weather station that I am building. The RI input on the serial port was exactly what I needed.

Regarding the debate over the amount of source code needed for publication, I think that Greg's article is just right. (A succinct but complete program with sensible commenting and a clear description).

Yours Sincerely,

Garry Boyce
116 Sheoak Rd
Crafers
S.A. 5152
Australia

P.S. Hope that you are enjoying your stay in Australia.

Thanks, mate. — pjp

Dear Rex,

I am most surprised that P. Lyle Mariam (CUJ letters, April 1991) should have assumed that your puzzles were aimed at beginners. I have been programming for quite a few years, and in C for the last three. I was pleased to be able to answer nearly all the questions correctly, though I certainly had to put my thinking cap on.

Furthermore, I like the way you gave the 'answers.' Most of the problems required informed interpretation of the C Standard, and deserved the detailed explanation they received. I thought the style and content of the answers was just right.

My only complaint about your puzzles is that there aren't any! They had rapidly become my favorite part of the magazine, and I am sadly disappointed by their disappearance. Is there any chance they will return? Preferably as a regular, monthly feature. (Are you listening PJP?)

Ian Cargill
Senior Software Engineer
Wyatts
Surrey, UK

Editors can only edit copy submitted by writers. Are you listening, Rex? — pjp

Dear Mr. Ward:

I agree with the points raised by Mr. Brad P. Smith in the letters section of the June 1991 issue of The C Users Journal regarding the use of one of the national networks for the distribution of C source code.

The issue that I would raise is that much care should be given to choosing such a network. CompuServe is expensive and so is BIX last time I checked into it. GENIE seems reasonably priced according to their last price sheet that I received. Delphi is one of the most reasonably priced services and it can be accessed through both Telenet and Tymet.

One of the things that really bugs me about both CompuServe and GENIE is that they insist on charging me a monthly "service fee" whether I use the service in a given month or not.

In view of your world-wide readership, the issue of accessibility to your foreign readers needs to be taken into account. Based on past experience, it is typically much more expensive for foreign users to access a U.S.-based service due to tariffs imposed by their local telephone service provider, but this may have changed somewhat in the past year or so.

I really enjoy The C Users Journal each month, please keep up the good work!

Sincerely,

James E. Truesdale
4645 LaGuardia
St. Louis, MO 63134

Living abroad has shown me any number of barriers to communication with U.S.-based services. I haven't found a good solution yet, either. — pjp

Mr. Plauger:

More and more, DOS-based C writers are faced with programming in protected mode using either the Microsoft Windows environment or a DOS extender. When these programs go out into the field however, we discover that systems often are configured for both expanded memory and extended memory. Expanded memory managers that are not in conformance with the VCPI or DPMI standard will usually cause Windows or the extender to crash, sometimes with a relevant error message, sometimes not. If the EMM is in conformance, there is usualy no problem.

An extremely useful C function would be to be able to test for the conformance of an EMM driver to the VCPI standard and then have the program provide a graceful resolution/error message accordingly. With a DOS extender, this could be done in real mode before the program itself actually runs in protected mode and causes a crash. It should be noted that detecting the presence of an EMM driver by the int 67h or int 21h function 44h (IOCTL) doesn't cut the mustard.

Sincerely,

Thomas Brown
Aries Systems Inc.
One Dundee Park
Andover, MA 01810

Good idea. Any volunteers? — pjp

Dear C Users Journal,

Regarding "Word Counting" by L.J.G. Schumerhorn (CUJ, June 1991), did anyone technically competent preview the manuscript — or were you folks just short on material? That WordPerfect 5.1 yields a higher word count than Schumerhorn's pet routines surprises me to no end.

The notion that "a text cannot contain more words than blanks plus one" is absurd. I ain't sure what's customary in Kansas, but — where I come from — punctuation characters [ASCII 33-47, 58-64, 91-96, and 123-126] often imply word breaks. (Kansas-must-be-much-closer-to-Oz-than-I-ever-suspected!)

Apart from this insufferable waste of white-space, your publication remains worth my time — my renewal check will arrive promptly. And — finally — please pardon my nastiness, I've had a bad day (a convoluted state machine is misbehaving!). Thank you for your time and trouble.

With my regards,

Dan J. Kolar
4901 West McGuire Road
Lincoln, NE 68524

Yes, you are being a bit touchy in my book as well. As always, I defend the right of our authors to take a simple view of the world at times. That happens to be just what many of our readers need, particularly the ones new to C. I'm glad we score often enough at your level of sophistication as well. The balancing act is never easy .— pjp

Dear CUJ:

Mr. Schermerhorn assumes a word is defined as a set of non-space characters followed by a blank. It ain't necessarily so.

When I worked as a an editor (Isaac Asimov's Science Fiction Magazine) we defined a word as six text characters. We skipped the title page and the header and footer, estimated the number of lines per page and characters (counting spaces and punctuation) per line, divided by six and paid the author on that basis. Since there were usually about 22 lines per double-spaced page and 65 characters per line, this came out to about 240 words per page.

It sounds as if WordPerfect may be doing something similar, although their ratio of bytes to words (4.3) is a bit low for the six characters per word rule we used. It is about right for five characters per word (and not counting control characters or headers or footers. I suggest Mr. Schermerhorn check the WordPerfect documentation.

Sincerely,

John Ashmead
139 Montrose Avenue
Rosemont, PA 19010

The word-counting program that Kernighan and I wrote for Software Tools was as simplistic as Mr. Schermerhorn's. It's amazing how closely various methods agree for a large enough sample, even if they differ in many small details. I barely resist making a snarky remark about what IASFM and other science-fiction mags pay for those words they count. — pjp

Dear Mr. Plauger,

I am a recent re-subscriber to CUJ. The tone of the magazine appears to be more academic than when I last subscribed. This is a Good Thing; cranial exercise is very hard to come by in print these days.

If you believe that critical mass is the driving force behind many a good project, please let me add the mass of this letter to the BBS proposals. In CUJ 9.6, Brad P. Smith suggested using one of the established BBSs as a gateway. This makes perfect sense:

1) Putting the library on a BBS eliminates the need to charge for media and mailing, which should make your accounting easier.

2) Easier access allows "browsing." If I have to mail away for code that might be interesting, I probably won't. If I can quickly download it, it is more likely to be looked at and used.

3) The BBS will most probably contain a message forum. This will allow CUJ to get more timely feedback about the magazine and library code problems.

4) Most importantly, the BBS is a natural publicity cow (like a "cash cow"). Every time some unassuming CompuServe member (whoops, my bias is showing!) happens to walk through the service looking for new forums, you get another potential subscriber.

The downside is that management of the forum will be much more difficult than managing the current library, just due to the sheer volume of messages that are more easily generated by BBS than U.S. Mail. However, if your ultimate purpose is to spread enlightenment about the C language, (and to me it looks like that is exactly your manifesto) there shouldn't be a question as to whether or not it should be done.

If you want practical advice on how to set it up, I suggest you talk to the Ziff Davis people (if they don't consider you potential enemies.) They have ZiffNet set up on CompuServe for PC Magazine, PC Computing, PC Weekly and a host of other magazines.

In closing, let me re-emphasize that a BBS for CUJ code would be a most outstanding tool.

Sincerely,

Matthew O. Persico
2846 East 197th St.
Bronx, NY 10461

Noted. — pjp

Dear Sir:

In regard to E. J. McConnell's letter in the June 1991, issue on graphics play routines, Bit-Mapped Graphics by Steve Rimmer (Windcrest Books/ McGraw-Hill, Inc., ISBN 0-0306-3558-0) might provide some of the information needed.

The book covers the file formats for MacPaint, GEM/IMG and Ventura Connection, PC Paintbrush PCX, GIF, and TIFF. Encoding and decoding of these formats is covered, plus LZW compression and decompression. Also discussed are high-speed monochrome and color screen drivers, PostScript printers, dithering, and format translation. Most of the code is in C with some in 8086 assembler.

Sincerely,

Susan M. Johnson
1515 Albany Circle
Rock Springs, WY 82901

Thanks. — pjp

Dear Editor,

I am a novice C programmer mostly interested in realtime applications. So far I have done almost all my programmming with various PLCs (ladder language) but am slowly turning toward a more flexible programming language.

C seemed to be the hottest, and the most capable language to manipulate bits. So I have chosen C.

I have decided to go slow on this and do some practicing at home before I start to do the first "real work." During practicing I got into a problem which is easily solved, but I believe there must be a more elegant way than I'm able to figure out.

Let's say you have a program with a number of options for the user to select. Depending on the selection, the user shall add new data, edit existing data, sort data, and so on.

My program uses a function I've called get_str which takes a char pointer (str_address) and an int (max_str_length) as arguments. This function stays in a loop until the Enter or Esc key is pressed. (I have seen more or less similar functions printed in your magazine.)

The problem arises when I want to call the get_str function from various places in the program. If I want the function keys to have different meanings depending on the calling function, I could have a number of switch statements to check which key is pressed and who is calling. However, I believe it must be possible to have a routine outside the get_str function that generates an "interrupt" each time a function key is pressed.

This is a principal question: Is it possible to have a routine working in the background that comes into action whenever a certain situation occurs, even when you are in a loop which does not test for this situation?

I hope you can help me out on this and I thank you in advance for any thoughts you might offer. I'm using Turbo C for MS-DOS.

Sincerely,

Per Chr Borgvad
Kontravn 4c
1400 Ski
Norway

You have discovered the need for "interrupt handlers." Check for that phrase in a few books on DOS programming. One of them should explain the mechanics at the level you need. And be careful — interrupts offer numerous opportunites for subtle programming bugs. — pjp

Dear Editor,

This letter answers your request for a source of graphics file format information, re: We Have Mail, CUJ, June 1991. In response to the reader inquiry concerning programming screen capture utilities in C, we submit the following source books:

Visualization Graphics in C, Lee Adams, ISBN 0-8306-7487-X, 1991, hardback.

Bit-Mapped Graphics, Steve Rimmer, ISBN 0-8306-3558-0, 1990, paperback.

Both books are published by Windcrest Books, Blue Ridge Summit, PA 17294-0850, and are probably available through the better libraries.

Visualization Graphics in C is a beginning tutorial for programmers just getting into the field and is loaded with valuable source code, including binary screen capture utilities. The book achieves the stated goal of the author, to provide a learning tool designed to teach graphics programming. We highly recommend this publication to anyone not already well-versed in this area.

Bit-Mapped Graphics is another invaluable source of C routines based on the five most popular image file formats. This book has become our standard reference for specific information on encoding, decoding, and the manipulation of image files. This reference also includes working examples of C source code for use with many popular display adapters and printer.

For Windows applications, most of the information is usable if a resource compiler is available to develop and bind the graphics file to an .EXE or .DLL. While the theory remains valid, considerable effort will be necessary to adapt the example code to the Windows platform. The TSRs and screen capture utilities are not conducive to the Windows program environment and will behave erratically. We have found very little reference information in the area of screen capture utilities for Windows and welcome any forthcoming articles or ideas.

Until Bob Montgomery (VPIC.EXE) decides to publish, perhaps your book reviewers can take a look at both of these excellent sources of information on graphics programming in C with a view towards the fastest growing field in PC business software — graphics!

Sincerely,

Robert T. O'Dell
Chief, Program Development
Phase IV Computer Graphics
12708 North Freeway
Houston, TX 77060

Thanks. — pjp

Dear Mr. Plauger,

In the June 1991 issue Mr. Todd Weiss corrected some mistakes in Stuart Baird's article "Using Large Arrays in Turbo C." Unfortunately, Mr. Weiss made a couple of mistakes of his own.

The first is one I'm surprised you did not catch — the statements about ANSI conformance. An ANSI-conforming compiler only needs to properly compile ANSI conforming programs. One restriction on conforming programs is that they not exceed any of the translation limits in section 2.2.4.1. One of those limits is that a single data object can be as large as 32,767 bytes. All of Mr. Weiss's arrays violate that limit, and so the compiler is under no obligation to compile them. So Turbo C is in conformance with the standard, at least on this point.

Mr. Weiss's befuddlement over the wraparound problem is due to his second mistake. He presumes that because far pointers are 32-bit quantities they are 32-bit integers — they are not. far pointers are composed of two separate and independent 16-bit unsigned quantities, one for the segment and one for the offset used by the Intel chips. Adding any integer value to a far pointer adds the value only to the offset portion. Since unsigned addition is wraparound, that's what happens with addresses as well. The following code demonstrates the problem rather nicely.

#include <stdio.h>
int main(void)

{
int far *ptr1, *ptr2;

   ptr2 = ptr1 + 32768;
   if(ptr2 == ptr1)
      puts("Pointers are the same!");
}

It is possible to have objects larger than 64K, but only by declaring such objects with the keyword huge. huge pointers are also double 16-bit items just like far pointers. The difference is that the compiler will generate extra code to ensure that the offset portion of the address is less than 16, with any excess divided by 16 and added to the segment portion. Changing the sample program above to use huge pointers instead of far pointers makes the pointers differ. These extra instructions make the resulting code both larger and slower, which is why they are not the default.

Perhaps it is time to persuade someone to write an article about addressing on Intel processors.

Sincerely,

Robert L. Milton
E.R.M.Associates
P.O. Box 1032
Agoura Hills, CA 91301

You're correct about the ANSI limitations on data-object size. Much of the machinery added to C for the 803x86 family is pure extension, however. At issue is reasonable or expected behavior, not what the law requires. Any number of articles have tackled various aspects of this thorny issue. For a broad overview, see my article in the February 1987 issue of Computer Language titled, "Son of PC Meets the C Monster." The title says it. — pjp

Dear Mr. Plauger,

I am writing to complain and let other readers know of extra financial considerations for choosing between Microsoft QuickC and Borland Turbo C.

First of all, when you buy QuickC you get two abridged manuals. If you want the complete set of reference manuals you must pay extra. Microsoft thinks on-line reference is sufficient. For some people that may be true.

Then there is the question of the font files. The QuickC manuals (even the extra ones you can buy) don't mention the royalty payments due to Bitstream if you distribute any font files with your program. According to the technician I spoke to at Microsoft, you must sign a contract with Bitstream for a license fee of $500. If you can only budget for a $75 compiler how can you afford $500 to distribute a font file with your program?

I read somewhere that Turbo C's manuals give you permission to distribute the font files with your program royalty-free. I'd like to know if this is true. If so, I will buy Turbo C (or Turbo C++ if it includes fonts). It's less expensive to buy another compiler that offers free use of fonts than it is to pay a $500 royalty fee!

In the May issue of The C Users Journal a letter from Gerhard Wilhelms mentioned how to get a free font editor from Borland. From what I've discovered so far, buying a font editor is another expense if you want to edit QuickC fonts.

It was Mr. Wilhelm's letter and Mr. Kolias's letter in the December 1991 issue which prompted my inquiries to Microsoft regarding the font files. Although the answer I received about royalties displeased me, I'm glad I avoided a potential lawsuit. My application requires fonts. I was just beginning the distribution phase of my project. Now, due to this technicality regarding royalties, I must go back to the development phase.

I don't know how QuickC and Turbo C compare otherwise (that's the disadvantage of commercial software compared to shareware), but I feel that Microsoft is obligated to its users to warn them of the required royalties somewhere in the license agreement or manuals.

To any Borland executives who might be reading this letter: Are you planning any upgrade offer to dissatisfied QuickC users?

Belinda Aboshanab
446 S. Lima Circle
Aurora, CO 80012

Fonts are yet another piece of intellectual property to add to the muddle over software ownership and royalties. The laborer is worthy of his hire, whether he crafts fonts, functions, or folk tunes. I'll bet there are permissions pitfalls even among shareware programs at this stage of evolution. I welcome any informed commentary on the state of the industry. — pjp

Dear Mr. Plauger,

I am writing in response to the letter in the June, 1991 issue of The C Users Journal from E.J. McConnell.

The only book I have found that deals with reading and writing different graphics files is Bit-Mapped Graphics by Steve Rimmer. Published by Windcrest Books in 1990, it covers .MAC, .PCX, .GIF, and .TIFF file formats. The code is written in C with assembly. For me, the use of assembly was a drawback since I'm still teaching myself C. However, the speed of assembly becomes necessary for quickly packing and unpacking graphics files.

The book also deals with graphics output, converting files between the graphics formats, and a lot of other valuable information. I would have liked to see more on graphics output to dotmatrix printers. However, that's probably a book topic in itself. If anyone knows of such a book, I'd like to know about it. To get a copy of the book write to: Windcrest Books, Imprint of TAB Books, Blue Ridge Summit, PA 17294-0850. TAB Books has a book club, and I've seen this book in their ads as one of the choices for the introductory offer. They also have the C Programming Series by Lee Adams which covers the topics of animation, simulation, 3D, CAD, and Paint programming.

Also, at this time I'd like to address the issue of a BBS. Rather than have your own BBS you could make the code listings available on other large BBSs, some belonging to software companies. I've seen other magazines do this, and unlike using CompuServe, as was suggested by Brad Smith, I believe these boards are free. Just to name a few:

Ithaca Street (303) 494-8868 — CO
Pathfinder (408) 246-0164 — CA
Magna Carta (214) 226-8088 — TX
Magma Systems (201) 912-0668 — NJ
C BBS (703) 644-6478 — VA

Sincerely,

Belinda Aboshanab
446 S. Lima Circle
Aurora, CO 80012

Thanks for the info. — pjp

Dear Mr. Plauger (via e-mail):

I have been reading your article in The C Users Journal about locale.h with great interest. What really was funny was that just last week our company had a seminar concerning the subject and I was able to act somewhat knowledgable because of what I had read.

When I mentioned that I had read about the stuff in The C Users Journal, I was asked to make a copy of the article and pass it around to our department. Since I notice that the entire magazine is considered copyrighted, I wanted to ask you or the magazine (since you are the editor) for permission to reproduce the series of articles and pass them around to our department.

If there is a problem, can you tell me what to do in order to get copies or permission? I'm sure my company will be happy to do what's necessary.

One more question, since I am writing you. I notice that you have written a book, The Standard C Library. What I'm looking for is a complete book describing the ANSI C standards with, possibly, a chapter or something just going over the differences between Standard C, as described by Ritchie and Kernigan. I'm real concerned (since many of the books came out before ANSI completed their decision on the standard) that the books I have are not complete. Do you have a recommendation for a book that would be complete? If not, do you know how an individual such as myself can get a copy of the actual standard from ANSI?

Thank you very much for your help. Keep up the great work with The C Users Journal. I'm considering submitting some ideas/articles myself soon.

Chris Carlson
carlson@support.newport.sgi.com

You have my permission to distribute copies of my article for internal use. I speak as the author, since I own the residual rights in this case. And thanks for asking — not everyone bothers to do so.

A complete summary of the C Standard can be found in Standard C, written by Jim Brodie and me and published by Microsoft Press. The summary of changes you're looking for can be found in Tom Plum's Notes on the Draft C Standard, published by Plum Hall, Inc. Both books are available from the C Users Bookstore, which invariably advertizes in The C Users Journal (oddly enough). You can obtain the ANSI C Standard from ANSI in Manhattan. — pjp