About a year ago I made the decision to leave the ranks of GWBASIC programming. After years of enduring the smug remarks about being an undisciplined GOTOer I decided that the time was right to begin my new learning experience. After months of research my compiler of choice was Turbo C v2.0 and my reference of choice is The C Users Journal. I use the word "reference" lightly because after reading your magazine from cover to cover every month for the last eight months I can honestly say that I don't have any idea what the hell you are talking about. I love it! I use your magazine to gauge how much I am learning by seeing how much of each issue I understand. In all fairness I must say that I can only study between projects and job assignments which leaves little time. I figure at this pace I've got to go another two years before I can develop a meaningful database application. But as of the June 1990 issue I am up to two pages and six ads of comprehension.

This quantum leap in learning is the direct result of Leor Zolman's File I/O tutorial. The pages are worn thin as I go back and forth knowing that someday it will all sink in (kind of like Calculus).

For the past year I have felt that my professionalism is lagging because I am still proficient in GWBASIC and have not mastered even the basic skills of file I/O in C. But three things happened in your April, May, and June issues that have me believing in myself again and not feeling so bad about my programming skills (or lack of them):

June — The Bad C Pun Contest. This led me to believe that not all C programmers walk around with a smug look on their face and a frowned brow.

May — The Obfuscated Code Contest. This led me to believe that regardless of what language we preach, we are all hackers at heart.

April — File I/O Tutorial (first installment). As I slid my ruler slowly down Listing #2 being careful not to miss a single comma, semi-colon or space for fear of being trapped in the debugger zone. There it was, on line 63, as big as life. And again on line 80. And 104, 110, and finally on line 118. There before my eyes was THE word......GOTO. Imagine, an intelligent, experienced and respected C programmer like Mr. Zolman using GOTOs. There's hope for me yet.

Please don't try to explain them because I wouldn't understand what you were talking about. Suffice it to say that I know why they are there. C will apparently dig holes like any other language that only a GOTO can climb out of.

By the way, are there any other secrets you're not telling. Like GOSUBs, DATA statements, INKEY$, CVI, CVS, or CVD. Keep up the good work and please continue to remember us Novices once in a while.

Mr. Zolman and all of the Editors; Thank you for a great series of articles (I think).

Bill Sacramone
27 Carpenter Road
Dudley, MA 01570

I asked Leor about these gotos. He feigned ignorance. —rlw

Even intelligent, experienced and respected programmers like myself can fail to check that the correct version of code makes it into the magazine listings. In Listing 3 of July's installment of my series, delete lines 23, 28 and 40. This should make the code a bit more understandable. —leor

Dear Mr. Ward:

Since my article, "A Date Object in C+ +", was published in the June 1990 issue, I have had the opportunity to implement the program in Borland's new Turbo C++. Doing so revealed several minor flaws and one larger one in the original version.

The functions DMYtoJulian() and JulianToDMY() (Listing 2, pages 61 and 62) contain several literal constants which should be denoted as long integers by adding the 'L' suffix. This addition should not cause any change in the actual operation of the code but should improve clarity.

Also in function DMYtoJulian(), the local variable Ja, Jm, Jy and Jul should be long ints, not unsigned long ints. Obviously, if years can take on negative values, arithmetic on years must be signed. The declaration of unsigned long ints is a remnant of some earlier experimentation I did with the function. For some reason it works with the Zortech compiler under the conditions I tested. The function must use long ints to work with Turbo C++.

Depending on which warnings are enabled, Turbo C++ will complain that the assignment to Year near the end of JulianToDMY() will cause a loss of significant figures. The warning can be squelched by surrounding the statement with #pragma warn sig- and #pragma warn sig+.

The last two problems occur in the function DateToString() (Listing 2, page 63). The variables c, Len and Pos are remnants of earlier work on the function. They and any statements that use them can be safely deleted. Finally, the call to calloc(), near the top of the function will generate a type mismatch error that can be fixed simply by casting the result of the call to a char*.

Sincerely,

David D. Clark
507 N. Division St.
Bristol, IN 46507

Dear Friends,

What a wonderful surprise to find a magazine devoted just to the C programming language. A friend of mine recently let me borrow his first copy of your magazine (July '90) and I was delighted. I found your ad for the public domain library and fell in love all over again. Here was the serious software source code that I have lusted after for the past two years (since I began to try to learn C). I have owned a Tandy Color Computer for about five years now and am presently running OS-9 Level II on a CoCo 3. The C language seems to be the preferred programming language for most serious non-assembly programmers and I learn better from example so your library is a God send.

I have included a photocopy of your order blank with the two disks that I wish to order first. I requested them to be in MS-DOS 5-1/4" double sided format because I don't know if one of those 100 formats you advertize includes OS-9 or not. If you DO have the Tandy Color Computer OS-9 Level II format available, I would of course prefer it over MS-DOS but I can read and write to MS-DOS disks as long as it is in ASCII or TEXT form. I would assume that the source code and doc files would be in ASCII would it not?

If you do not presently offer OS-9 Level II format disks, I would urge you to consider it. I will most certainly pass the word to my friends and to the "Rainbow" magazine about your library. I'm not sure if they are aware of your existence. Believe me, we in the CoCo community need all the help we can get at present since Tandy seems to have decided the Color Computer is not worth supporting. This is not the case and many of us users are not happy with Tandy at the moment. We in the 6809 world have created our own new version of the CoCo. At present, two vendors are presenting a 68000 version of the Color Computer and they look most promising. I paln to upgrade to one of them as soon as I can get more info on them both and decide which one I want and can afford.

In the very near future, (August), it is my intention to subscribe to The C Users Journal. I live on a fixed income at present and so must pace my expenses to my income. You know how that is. I know that I will learn a lot from it. It's tough trying to learn a programming language on your own but each day it become a bit clearer. Your magazine will help fill my needs. I hope that I will receive a quick response from you folks with regard to the disks that I am ordering. Our "OS-9 Users Group" has a similar library but they just can't seem to get it to you in less than 10 to 12 weeks and it is not nearly as extensive as your library. Most discourage that.

Best Regards,

James F. Carter
529 S. Speer
Monticello, AR 71655

We should do much better than 10 to 12 weeks. In fact our internal goal is to ship all standard format orders (that includes MS-DOS) in two working days.

We researched MS-DOS to OS-9 conversion software and hardware about a year ago and decided that the available systems were too technically demanding and too expensive for our needs. If you can read MS-DOS, that's probably your best alternative for the forseeable future.

Our library does hold some programs (see CUG132) developed specifically for the Color Computer, but unfortunately they weren't developed under OS-9. Even so, you should be able to find many directly useful filters and other text-based applications in the library. — rlw

Dear Editor:

Not a question of changing style or of good style, standard English requires the titling of figures and charts.

Regrettably The C User's Journal stylistic changes have failed to correct a long standing disreputable habit of neglecting to label graphics. This failure is inexcusable for two reasons. One, you're publishing a professional magazine, which requires the oversight of those versed in English rhetoric, along with its historical forms of graphic presentation; and two, as editors of programming code you should highly regard adequately commented code, comprehensible diagrams, clear flowcharts, and so on.

By remedying this situation the Journal will not only reflect greater quality and consume less reader's time, but also make C clearer to those thinking it obscure.

Sincerely,

John Rieley
2295 Andrews Avenue
Bronx, NY 10468

Robert Ward,

In his C++ article in the July 1990 issue, Ali Hazzah states:

"A structure may only contain variables."

Although this is true in C, it is not in C++. A C++ struct is exactly the same as a class with all members public.

Bruce Eckel
Revolution 2 P.O. Box 760
Kennett Square, PA 19348

As usual with C+ + details, I'll have to plead ignorance and defer to experts like you. Thanks for writing. — rlw

Dear Robert,

I felt I must write to acknowlege Leor Zolman's series of articles. As a serious student of programming, I was pleased with both the program and his explanations, I do not know your reader make-up, but I would judge that most are much farther advanced than I. I do hope there is enough interest in his work to keep him busy with similar projects. Of course I read and enjoy all the other writer's work. I am not into C++ yet, but Leor's article caused me to sit down and type in the code and go to work. By the way, the line numbers reduce typo's remarkably. Keep up the good work.

Sincerely,

Floyd A. Young
2425 Bissonnet St.
Houston, TX 77005

Leor's series has been very well received. We've already settled on a topic for another series. As soon as we can complete some internal programming projects, he'll get busy with some more writing. —rlw

Mr. Ward,

I read the article "Using yacc Or lex Twice In One Program" by Don Libes. It discussed some useful programming techniques, but part of the motivation for using these techniques was flawed. It is not necessary to "use yacc twice" in order to have multiple parsers in the same program. There is a relatively simple technique that can be used to allow multiple parsers to be combined in the same yacc grammer.

If we have two grammars called grammar_a and grammar_b they can be combined by writing

%token yySTART_a
%token yySTART_b
%%
grammer    :  yySTART_a grammar_a
           |  yySTART_b grammar_b
           ;

yacc-generated parsers keep the current token in a variable called yychar. Normally at the beginning of the parser yychar is initialized to -1. The value -1 is special for yychar. When yychar is set to -1 the parser knows that it is time to call the lexical analyzer to get the next token. To make the first token a parameter to the parser.

1. Modify the function yyparse so that yychar is declared as a parameter.

2. Remove the declaration of yychar as a local variable.

3. Remove the statement that initialized yychar to -1.

Sincerely,

Mark Grand
GeoMaker Software
P.O. Box 273124
Concord, CA 94527-3124

Thanks very much for the tip. If others out there have tips for using yacc or lex, I'd really appreciate seeing them. Just send it to me in a letter, and I'll print it here.

If you know of good resources for lex or yacc documentation, you might mention that too. I think these are important tools that are unnecessarily difficult to use because documentation is so scarce. — rlw

Dear Robert,

I had so much fun in reading the Publisher's Forum (CUJ June 1990) and was surprised to know what the Bad C Pun contest was all about. Perhaps, I was so busy at the time when you announced the contest that I did not pay much attention to it. I really enjoyed it. I suggest that you create a small column in CUJ and publish some of the entries you received. This can add humor to your highly technical journal. I'm sure a lot of C-soned programmers would enjoy it also.

As they say, "It's Better late than never". So, I'm sending some of my C Puns, too (just for the sake of fun).

1. What did Dennis Ritchie say to Ken Thompson after designing C? To C is to B-leave!

2. A young programmer told his girlfriend, "Programmers often fall in love with Pascal and end up happily married to C. Me, I still love U because you're Uniks".

3. She sells C shells by the C store.

Also, I have a response to Mr. Alexander Vladimirovich Pavlov letter (CUJ April 1990 p.139). You can still use libraries whose titles begin with any of Borland's library names (i.e., CS..., CM..., CC..., CL..., CH... ). Just remember that when you do so, you override the standard library for the particular model that you are using. So, you have to explicitly specify in your PRJ file, the libraries (EMU.LIB or FP87.LIB, MATHS.LIB, CS.LIB) that should be used together with your own library (CHESLLIB. LIB). In that case, you don't have to rename your library to LIBCHES. LIB.

I also have an entry in the Great Name/Obscure Code Contest.

if (virgin)
   ...

It came from a report program written five years ago by a friend of mine. Sorry, I can't disclose his name.

Sincerely yours,

Victor Caballero
World Health Organization
UN Avenue, P.O. Box 2932
Manila, Philippines

Maybe you should have saved those puns till next year ... and captured some prize money.

We'll pass your variable name to Ken Pugh, but It's meaning seems perfectly clear to me. — rlw

Dear Robert,

I must congratulate you, your staff, and your fine team of contributors on a consistently well-produced and informative magazine. The Obfuscations this year were wonderfully hideous — the modern equivalent of catharsis in the Greek tragedies! (James Joyce called it catsarses, but that's another story.) I once suggested, tongue-in-cheek, a tautological APL Obfuscation contest at SIGAPL (ACM's APL special interest group), but they are, with a few exceptions, touchy and humorless on this subject.

Your excellent and growing coverage of C++ is most timely in view of the arrival of Borland's lowcost implementation. All the signs are that Turbo C++ is selling well beyond expectations. Since it offers K&R, ANSI-C and AT&T version 2.0 C+ +, I suspect that many of your readers will be tempted into exploring Bjarne's baby.

Bill Plauger's honest accounts of the ANSI-C committee's travails are greatly appreciated. On the metaphysics of malloc(0), you may be interested in the solution that Tom Clune and I crafted the other week. If there are exactly zero bytes available, malloc(0) succeeds, returning a pointer to the byte just beyond the (full) heap. If 1 or more bytes are available, an error message "Too much memory available" is displayed, and the call returns a pointer to some vulnerable part of the user's code.

Regards to Donna and all,

Yours sincerely,

Stan Kelly-Bootle
The C Users Journal Official Bad C Pun Adjudicator &&
Contributing Editor, UNIX Review && Contributing Editor, Computer Language

Thanks very much Stan. It's nice to hear from you.

As for your malloc() "solution", it's clever — but only because it's not in a real runtime package. —rlw