I just read the December issue of the CUJ and thought it was quite good. It had more useful information than most of the CUJ editions I've read.

Listing 1 in Rex's article is something I've always been amused with. I even thought of a few more that are even less obvious:

a[i]     == i[a]
        == *(a+i)
        == (a+i) [0]
        == 0(a+i)

a[i] [j] == 0[a+i] [j]
        == j [0[a+i]]
        == 0[0[a+i] + j]

Second, there was a letter from Firdaus Irani asking about:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int comp(unsigned char**, unsigned char **);
unsigned char *list[] = { ... };

main(){
   int x;

   qsort(list, 5, sizeof(unsigned char *), comp);
   ...
   }

Cray Standard C, Release 2.0.1.2,
P/YMP Version
C Front-end  Version 059  CMCS
Back-end Version 386
Compiler Generation Date = Nov 1 1990
Compilation Date and Time = Thu Nov \
29, 1990
   09:34:04

 *** *** SC151 [warning ] File = \
yy.c, line = 11:
The function call argument #4 is not \
assignment compatible.

TOTAL WARNINGS DETECTED IN yy.c: 1

Compilation Execution Time = 0.560350
seconds

My reading of the standard is that this is correct. The function comp must be assignment compatible with the fourth argument to qsort:

extern void qsort(void *_Base,
   size_t _Nmemb, size_t _Size,
   int (*_Compar)(const void *,
         const void *));

int (*pf)(void *, void *) = comp;

char **q;
void **p;

p = q; /* not assignment compatible */

This was a compromise we arrived at when trying to figure out what to do with things like

int **p;
const int **q;

That's my recollection anyway. Talk to you later.

Tom MacDonald
Cray Research

Thanks, Tom. (To our other readers — Tom MacDonald is one of the more active contributors to the standardization and evolution of the C language. He made major contributions to the floating-point specifications in <float.h> and <math.h>, among other thing. He also participates in the on-going work of the Numerical C Extensions Group.)

The definition of the array subscript operator leads to all sorts of craziness if you depart from the most conventional usage. None of the forms you and Rex Jaeschke explore are necessarily "wrong," but they can sure mislead.

Your analysis of type compatibility among pointers to pointers is on the money. I believe Tom Plum anguished quite a bit about the problems the C standard causes with bsearch and qsort users. I don't think the rules we ended up with are either incorrect or onerous, but they do make us old-line, seat-of-the-pants C programmers think a bit harder. — pjp

Dear Sirs

I was left in a most confused state after having read the review of Menuet by Mr. Volkman in "Quick Takes" in the CUJ, Vol. 8 No. 12, pp. 101. Correct me if I err but, in contrast to the conclusion reached by Mr. Volkman, is it not desirable that a GUI not provide intertask comunication and other attributes associated with an operating system?

Perturbed,

J. Ue Parrot
Chicago, IL

The distinction between a GUI and an operating system can be pretty academic. If you want to support multiple window, cutting and pasting between windows, and background processing, your display manager had better at least be on intimate terms with the machinery that shuffles processes.

The functions of GUI and scheduler are distinct. Each is complex and difficult to implement. Each has serious performance requirements. All that argues for keeping the two functions distinct, as you point out. In real life, however, designers have yet to do so without serious performance penalties. — pjp

Dear C Users Journal,

I have never written to a magazine before and I usually avoid all arguments defending one computer language against another. But after reading Rodney M. Bates' letter in the January issue I feel impelled to express myself — enough is enough. Comparing the latest incarnation of C (or any other language) with ISO Pascal is like comparing a 1990 Buick with a Model-T. Have any of you rabid C (or Modula-2) types looked at a Turbo Pascal compiler lately?

Let's begin with "no Pascal that I know of has separate interface and implementation modules." and the "popular UCSD Pascal...force(s) massive recompilation." Turbo Pascal has supported private and public modules for years now. In the masses of code that I am currently wading through I am working with upwards of 50 different files in at least 3 different directories. Using a command line switch tells the compiler whether I want to "make" some of them or "build" all of them (sound familiar?). And it's fast — I mean fast the way no C compiler is. And that conclusion is based upon my own experiences using C on the same machine. (Yes, Virgina, I do program in C also.)

The statement about "popular UCSD" only serves to emphasize that Mr. Bates has not looked at a Pascal compiler for at least 5 years. (And in this business, that reads 50 years.) UCSD Pascal's popularity has declined probably in direct proportion to the popularity of the old Apple II, and in the microcomputer world, Turbo Pascal is the de facto standard.

TP 6 supports units, separate compilation, pointers to functions, bit manipulation, MS-DOS register types and interrupts, oh — and of course objects. I could go on and on. And it's fast — fast — fast with a smart linker that ignores what you don't need to use. No inflated code here, thank you.

In the same vein, years ago when I was taking a course in C, the teacher proclaimed that "you can't do bit manipulation with Pascal." TP has supported the operators shl (or <<), shr (>>), and xor (^) since day one. Okay, I can't define a structure composed of bit variables in Pascal, but then, neither can I manipulate sets in C.

The real point — every language has its own strengths and weaknesses. "Real programers" should be at least bilingual so that when the ideal development environment becomes available they can take full advantage of it. What environment you ask? — the one where you can mix at least four languages with ease. Like some assembler for communication work, C for pointers to huge arrays, perhaps Prolog for a database and then Pascal for maintainability — and sheer elegance.

Sincerely,

Barbara Argilo

Several dialects of Pascal make up for one or more of the deficiencies in the language definition put forth by Wirth. Several implementations have excellent development support. Some produce excellent code. The fundamental problem with Pascal has always been a lack of standardization for many features essential to serious development, such as separate compilation and manipulation of files by name. Your code can thrive in one environment and not survive porting to another.

You don't have to be a language bigot to observe that Pascal has diminished in popularity over the same period that C has thrived. The bigotry appears only when you contrive explanations for these trends. If you argue from emotional bias instead of looking at verifiable facts, you indulge in a form of bigotry.

Programmers should certainly be comfortable in more than one language, if only to appreciate the strengths and weaknesses of their favorite one(s). — pjp

Dear C Users Journal,

There are a few minor fixes in Louis Baker's article (CUJ Jan. 1991) First, the correct address is Zortech Inc., 4-C Gill Street, Woburn, MA 01801. The correct phone numbers are (617) 937-0696, fax (617) 937-0793.

Concerning your comments on Zortech and Turbo C++ on page 125, if you run out of memory, you are not necessarily out of luck. With version 2.1 and beyond, you can use the Rational DOS Extender technology (-br compiler flag) which puts the compiler into extended memory, freeing up that space for your program.

On page 126, the Zortech v2.1 and above linker no longer mangles the names in its error messages. It is a native code linker. Also, Zortech supports the cdecl as well as the extern C keywords. The extern C keyword is ANSI standard.

Marc Brockman
Zortech, Inc.
4-C Gill St.
Woburn, MA 01801

Thanks for the clarification. — pjp

Dear Mr. Ward:

Since the first C Users Journal arrived at my home, I have eagerly awaited every following issue. I used to subscribe to a plethora of magazines, but since have reduced them to this one. Good job and keep it up!

Besides my work in MS-DOS and VAX/VMS, I have also worked on the THEOS-286V operating system. I have yet to see any reference to it in this magazine. If there are any CUG members who also use this operating system, I would love to hear from them.

I also caught a reference to the BBS operated by R&D Publications. If it is something useful to CUG members, how do I obtain access?

Thank you for your attention.

Aaron N. Cutshall
LZA Computer Resources
4233 Casa Verde Dr.
Ft. Wayne, IN 46816

THEOS-286V is a new one to me. Anybody have any information on it? As for the BBS, R&D hasn't put up any special customer services on it the last I heard. Should that come to pass, you will read about it here first. — pjp

Dear Mr. Ward:

In your January 1991 issue, Tom Plum provided some insight on C compiler validation services being offered by a commercial company, the British Standards Institute. I would like to add to the information he provided by shedding some light on the certification process being used by our own government.

Our government's National Institute of Standards and Technology (NIST), formerly the National Bureau of Standards, provides the compiler certification service for all US government agencies, such as the Departments of Defense, Commerce, Energy, etc. This certification is required for any vendor who wishes to sell to any US government agency, and is the only certification required by law in this country. The government uses a standard called a Federal Information Processing Standard (FIPS), which is usually the same as the corresponding ANSI or IEEE standard from which the FIPS was adopted. In the case of C, NIST is adopting a FIPS-C which is the same as the ANSI C Standard, with some additional requirements.

NIST has been performing language certifications for years on other FIPS languages such as Pascal, FORTRAN, and COBOL, and will likely begin C certifications sometime this year. There are a number of points regarding C certification that your readers should be aware of:

1. Only NIST can perform such certification.

2. The NIST will use only the ANSI C validation suite (ACVS) supplied by Perennial as the certifying test system.

3. Those wishing to obtain certification must be ACVS licensees.

The value of a NIST certified compiler should be apparent to anyone. I agree with Tom Plum that compiler vendors should take steps to achieve certification. However, since these certifications are not free, vendors should make informed decisions regarding the relative value of certifications and how to obtain them. It's not clear what value a BSI certification has, if any, particularly here in the United States.

Sincerely,

Barry E. Hedquist
President
Perennial
4699 Old Ironsides Dr., Suite 210
Santa Clara, CA 95054

The folks at BSI tell me that the U.S. government has certain obligations under the treaty they endorsed as a member of the ISO. One of these is to provide reciprocity with validation services offered by other member nations. You can imagine what an economic impediment small companies would face if each member nation could demand separate validation for products requiring standards compliance.

I have even heard some Europeans argue that the shoe is on the other foot. Because NIST insists on producing a FIPS standard that is not exactly the ANSI standard, FIPS certification may not be acceptable to customers requiring ISO C conformance. But the U.S. government is obliged to honor an ISO certification from any member-authorized body.

As for me, I dunno. I am certainly no expert on the legalities involved. I happily disclose that Tom Plum is more than a good friend. (Our wives are twin sisters.) I observe that significant profits are at stake for the small companies providing validation services around the world. Clout with major vendors and purchasers of C compilers is an important issue. I also must report more than a little unhappiness with the high-handed way NIST behaves in the standards arenas that I care about. To me, they often appear coercive, unresponsive to the community they supposedly serve, and more than a little self-serving in their financial dealings. I emphasize, however, that these are personal opinions.

Thank you for writing. — pjp

Dear C Users Journal,

I have recently purchased Turbo C++. What percent of your articles are applicable to Turbo C++? Perhaps an index of past issues may be helpful. Thanks.

Gil Hoellerich
2617 Country Way
Fayetteville, AR 7203

I use Turbo C++ myself for most of my development work. Mostly, I use it for the ANSI C compiler hidden inside, not to mention the comfortable development environment on my PCs. I can tell you that essentially all the C code that has gone into recent issues of CUJ will work fine under Turbo C++. Code that cannot is usually identified as a specific dialect, or making use of nonstandard library functions. Quite a bit of the code we publish is actually developed under Turbo C or Turbo C++.

The C++ stuff is just a bit more problematic. That language suffers more from dialect variations than its older brother. Extensions to the Standard C library, beyond the basic C++ I/O, vary the most. Nevertheless, our authors tend not to push into the dark corners of C++ except when they are telling cautionary tales.

An index sounds like a great idea. The next time Robert finds someone sitting around the office looking bored, he can discuss the matter further. — pjp

In fact, we have several initiatives under way. We should have some news "real soon now." — rlw

Dear Editor,

This example of implementing a state machine is a welcome article. However when I tried the listings example, the following errors were found:

1. Listing 1: MAX_FUNCS should be added as a #define with a value of 5. It is referenced in listing 3.

2. Listing 2: The Next_State values of S_PLAY under the states S_FAST_F, S_REWlND, and S_RECORD are wrong. The next states remain the same as present states.

3. Listing 3: In the function driver, under the "find the state" comment, a reference to s_table[i] is missing the underbar.

4. The state diagram (and table) does not allow for the case where the tape is left in the VCR and power turned off. When power is turned on, the tape must be inserted before one can get to the READY state.

Suggestions for improvement:

A. Listing 1: The valuef 5 in defining the state table structure (*flist[S]) should now be changed to MAX_FUNCS.

B. Define a MIN_CHAN (of 2) for the VCR to cycle from 2 thru 13.

C. A follow-up article on "Alternative Organizations" mentioned by the author is in order.

Enjoy the Journal — keep up the good work!

Don L. Jackson
P.O. Box 681
Gilbert, AZ 85234

The author, Paul Fischer, replies:

Mr. Jackson,

Thanks for the comments. Sorry for any inconvenience errors 1-3 may have caused. Regarding number 4, there are two solutions.

As I stated in the last paragraph of the section entitled "Example," a function should be added that causes an automatic ejection of the tape in any transition to the S_OFF state. I consider this function to be "internal device operation" and did not list it. I do agree my decision not to list it causes confusion on the operation of the VCR in that case.

Alternatively, some designers prefer to move to a "transition" state and execute a function that checks the outstanding condition (in this case if there is a tape present), and then generate an internal event to move to the correct state and execute the appropriate functions. For this presentation I was attempting to keep the diagram and state table as simple as possible. For that reason I did not apply this alternative method.

Thanks again for your comments.

Paul Fischer
P.O. Box 6 81
Gilbert, AZ 85234

Dear Mr Plauger:

I read with interest your editorial in the C Users Journal of December 1990, particularly with respect to your forthcoming sabbatical in Australia!

Many of my associates, not least myself, would be extremely interested in meeting you during your stay here. Are you going to visit Melbourne, Victoria, at all? While my company is particularly interested in Windows 3.0 and OS/2 A.P.I's, we run a bulletin board which has a large and devoted group of C programmers. We have regular (monthly) meetings and would love to have you along one evening if this were possible.

I look forward to meeting you in 1991. Please don't hesitate to call should there be anyway in which myself or my associates can be of assistance to you during your stay.

Yours faithfully,

Stephen Moignard
Windows Solutions 1 Jamboree Ave.
Frankston South
Victoria, Australia 3199

Thanks for the invite. My family and I do plan to travel about Australia, and I have already received a staggering number of offers to visit and speak. You can reach me via the Computer Science Department at UNSW. — pjp