I am not much of a letter writer, but after reading the July 89 issue of the C Users Journal I felt I could save some of your readers a lot of time tracking down a problem with the Microsoft C, version 5.10 memory allocation routines. Enclosed is a listing and the output from the program.

This may help Steven Isaacson who is having memory allocation problems using Vitamin C. I found this problem after a week of tracking down a memory leak problem in a very large application. My final solution was to write my own malloc()/free() rountines that call DOS directly. This will let the DOS allocator do what it is supposed to do. No time penalty was noticed in our application.

Note if you do write your own malloc()/free() routines, call them something else! MSC uses these routines internally and makes assumptions about what data is located outside the allocated area. I always use a malloc()/free() shell to test for things like memory leaks and the free of a non-allocated block. It also will give you an easy way to install a global 'out of memory' error handler.

The code supplied by Leonard Zerman on finding the amount of free space in a system is simplistic and very limited. A better routine would build a linked list of elements and then the variable vptrarray could be made a single pointer to the head of the list. The entire routine becomes dynamic, much more robust, and there is no danger of overflowing a statically allocated array. See the supplied code for an example.

The linked list implementation has the side effect that it will work on a virtual memory system. Why you would want to do this is beyond me, but it could be considered a very time consuming way to find out what swapmax is set to on a UNIX system.

If you have any questions, please contact me. My phone number is (408) 988-3818. My fax number is (408) 748-1424.

Sincerely yours,

Jim Schimandle
Primary Syncretics
473 Sapena Court, Unit #6
Santa Clara, CA 95054

Thanks for the information. We've included your code in Listing 1. — rlw

Dear Mr. Ward:

I'm new to programming and need to extract information from old mainframe files. Each file has its own annoying attributes.

Some files are reports for printing on 132 column paper with headers on each page along with errors in tabulation and decimal point alignment.

I'd like to know enough about grep, awk, sed, and tr so I'm not reinventing the wheel with my C programs for file manipulation.

Where can I find an understandable and brief overview of these UNIX tools? (I know nothing about regular expressions, scanning, and syntactic analysis.)

Sincerely,

Orion C. Whitaker, M.D.
400 Brookline Ave., #22F
Boston, MA 02215

I suggest The UNIX Programming Environment by Kernighan and Pike. This is a tidy little book that does more to explain how the tools work and work together than any other book I've seen. While it's insightful, it's also a good teaching text.

You should also consider The Awk Programming Language by Aho, Kernighan and Weinberger (the A. W. K. in awk).

If our readers know of other texts that do a good job of explaining how to use the UNIX language-oriented tools, I'd like to hear from you. — rlw

Thank you for your letter/brochure. First, I have some questions. I studied BASIC last Semester at Comm. College, and would now like to learn C. My major problem is MY computer. I have a Commodore 64 with 256K RAM expansion, and plan to use Abacus Software's Super C Compiler 64. I am a retiree with little prospect of buying a new computer.

1. Do you offer much in this format, or am I butting my head against a wall?

2. Would it be practical for me to attend a class where they are using, probably, IBM compatibles, and do my homework on my system? Would work developed on my system operate on "IBM"s? The disks are not compatible, but could my work be 'retyped' into the "IBM"?

I have Standard C by Plauger & Brodie, and Transactor Magazine has articles which look like they will be useful when I learn more.

Les Maynard
P.O. Box 915
Palmer, AK 99645

Unfortunately, we can't write Commodore disks. However, it's my understanding that if you have the right Commodore drive you can get a program that will let you read MS-DOS disks directly.

Whether you can do your C homework on your Commodore depends on several things:

1) Is your instructor willing to accept Commodore output. If you have to run your work on an MS-DOS host to make it acceptable, it probably won't work.

2) What subjects and exercises will the class focus upon? If writing direct to the IBM video display is one of the exercises, it probably isn't reasonable for you to try to work along on the Commodore. If, on the other hand, the class will confine itself to general, portable language features and concepts, you will have less trouble.

3) How adept are you at researching your own system? At some point (probably several points), a classroom illustration isn't going to work on your machine. It really isn't fair to expect the instructor to research the problem for you. Can you find your own way?

4) Is your Commodore implementation complete enough to support the scope of the class? Will you be asked to write programs that exceed the memory space? Will you need doubles? Will the exercises require elaborate pre-processor capabilities?

At the very least you should have a serious talk with the instructor before you enroll.

Whether work you develop will run on an IBM depends entirely upon the code. If you confine yourself to generic file processing and discipline yourself to avoid or at least properly hide any Commodore peculiarities, then your code should run in the IBM environment. (You might find some helpful ideas in Rainer Gerhard's story in this issue.) Please note these are major ifs even for very experienced C programmers. — rlw

Dear CUG,

I am writing to warn you and other users of the problems I have found with LEX part 1 and 2 on disk number 172 and 173. The program generates code which crashes the system when run. The problem is in llstin(). If _tabp is NULL, it assigns it to the return of lexswitch(). lexswitch() returns a pointer to the previous table, which is NULL when first cared. The results is _tabp being set to NULL forever. Since this table contains pointers to functions, the program jumps off to an unknown address. The source code that was provided will NOT generate this code, indicating that the exe file was not built from this source! So, I rebuilt it and, in testing, found the new exe produced different tables than the release program did.

There are various solutions to this problem. One is by setting _tabp to the location of the table in the .lxi. The solution is to edit the generated source file each time and removing the assignment statement to _tabp in llstin(). Or you could alternately change lexswitch() to return the new value. I don't like the last one because all the documentation states the return value is a pointer to the previous table. Since I am using the -s option, I edit the file as there is another problem with that option.

The problem with the -s option may only exist with Microsoft C. llstin() is declared as a void at the beginning. The function itself is NOT. The compiler produces a diagnostic error. With the incorrect source, the only way around this is to edit the file. (A REAL PAIN if you are using a make file to build the final program.)

I also have a copy of "Bison". It has worked very well with one exception. I found I had to include stdlib.h in simple.prs in order to get rid of several warning messages under certain conditions. One might include it inside the .y file, instead. By placing it inside simple.prs I don't have to remember to put it inside the .y. In general, I've found bison to be GREAT.

Keep up the good work, and good luck.

Sincerely,

Frank Veenstra
24797 Metric Dr.
Moreno Valley, CA 92387

Yes, the .exe and source files are out of phase. We'll test your fix and remaster the volume with the fix. When we have a new master we'll announce an upgrade in the New Releases column. Thanks for the help. — rlw

Mr. Robert Ward:

In the May, 1989 issue of the C Users Journal, Timothy Prince presented a rather eloquent and detailed article entitled "Efficient Matrix Coding in C". However, I would like to bring to your attention, excuse me if someone already has, an error in that article.

Mr. Prince asserts the following to be true:

a[i][j] = *( &a[0][0] + i * I + j )

float a[I][J] ;

a[i][j] = *( &a[0][0] + i * J + j)

I would also like to take this opportunity to commend you and your staff on producing a Journal that is superior technically than all the other superficial computer magazines that I have read. That May issue was my first copy of C Users Journal and it certainly will not be my last.

Sincerely yours,

Girish T. Hagan
27401 Via Olmo
Mission Viejo, CA 92691

Ah yes, the hazard of too much FORTRAN and Pascal. Thanks for correcting our slip — and thanks for the kind words. — rlw

Dear Robert,

I have been a member of the C Users' Group for quite a long time now, around the seven to eight years mark. Over this period I have kept all of your newsletters and your present The C Users Journal publications. I have watched the evolution of the Journal with great interest.

During your 'early days' I often reread some of the newsletters when I needed some information on a particular piece of code, or on a bug which another member had discovered. But time seems to compress as you get older. These days I rarely have the time to re-read articles, unless it is important that I do so.

WHY is he telling me this...do I hear you ask? Well, I hope I have set the scene properly because I assume you have many more readers than just Phil Cogar who have difficulty in finding enough time to squeeze in their preferred reading. Professionals in any line of work tend to be busy people.

Which brings me to the August issue of the Journal and, specifically, the article by Denis Schrader on the FOR_C Translator. Not that I am at all interested in FORTRAN_to_C translators but I always read the Journal from cover to cover and I hope my comments will assist in raising the standard of the Journal even further.

With respect to Denis Schrader, who I hope does not take offence that I have selected his article to point out what I believe is wrong with some of the User Reports, I would like to direct your attention to this article with the plea that you consider setting certain standards for authors to write to for future User Reports.

So, and without wishing to offend Denis, let me start by asking you to instruct your authors to make their reviews complete (or as complete as they can in the circumstance) as they stand. Don't presume the reader either has access to, or the inclination to look up, an earlier review. Of course rules are meant to be broken so you might give a reference to something written within the previous several months, but I suggest two years is a bit too long.

I refer here specifically to the words-"...which I reviewed in the August 1987 issue...However, comments in this review will point out improvements which have occurred since the release of earler verisons of the product."

Point 2, back up specific comments with specific information. For example if you say—

"The translator will pay for itself quickly in saved programmer hours."

then you should also say how much it costs, both the List Price and, if you know it, the street price.

Point 3, if we are talking about a specific product then either cut out or cut down on the generalisations. An example of this is the comment (statement?)—

"The translator translates almost 100 percent of ANSI Standard FORTRAN as well...extensions."

If the reader is reading the User Report because he or she wants to be better informed about the product (and isn't that the purpose of the User Report?) then, in this case, unless we are told-

-Whether this (the non-translation of the FORTRAN code) is a transient thing. In other words do you have to check each piece of translated code for small errors (perhaps for large errors...I don't know and the Review doesn't say) which might translate to bugs in C; or

-Whether this is systematic and the FOR_C translator only fails to properly translate certain pieces of FORTRAN code properly into C. In such a case does the translator 'flag' the offending pieces of code so they can be corrected using the recommended, known conversion; or

-If your translated C code compiles without the compiler complaining to you, does this mean the code is a 1-for-1 translation of the FORTRAN routine, or not;

and so on.

It seems to me that a generalised comment of the type mentioned above does little (nothing?) to better inform the reader about the merits or otherwise of the product.

Point 4, comparisons are odious (or so we are told) but they seem to abound in product reviews. My point is that partial comparisons tend more to mislead the reader than to inform him/her.

In other words we are talking here about a product which translates FORTRAN code into C code. We are not told WHY it is desirable to do this if you already have good, de-bugged FORTRAN routines you wish to incorporate into C programmes. Please correct me if I have got it wrong but, as I understand the situation the Microsoft family of microcomputer languages allow you to generate files compiled in Basic, C Pascal, FORTRAN and assembler any and all of which can be linked into a run-time file as required.

I am (most certainly) NOT an apologist for Microsoft but I do suggest a reviewer has not properly informed the reader as to the merits or otherwise of the product without at least canvassing other alternatives. If Microsoft, for example, have a family of languages which can do the job in another way (you'll notice I didn't say 'a better way' because I don't have a clue which is the better approach, the Review didn't tell me) then the Reviewer should at least mention this.

In other words alert the reader to other possible alternatives, at least. The preferred option would be to make a comparison between the competing products and compare features, strengths and weaknesses.

So there it is. In summary my four points are—

Point 1- Make the review as complete as possible in the spacce allowed. Don't ask the reader to look up other references. We aren't dealing with a scientific paper, just a product review.

Point 2- Give specific (factual) backup to specific comments. It's not that we don't trust reviewers to be objective, but we are discussing opinions here, and my opinion may well differ from the Reviewer's if I am given the opportunity to see what his\her opinion was based on.

Point 3- Leave out generalisations, at least if we are discussing one, specific product. Generalisations are OK if we are discussing a 'family' of products. Who was it said—

'All generalisations are false.'

Or perhaps I got that wrong?

Point 4- If you believe comparisons (with products from other sources) make the review stronger, then by all means put in the comparisons...but at least try to cover the best alternatives to the product being reviewed. Anything less then you are misleading your readers.

I know it has been tedious, but that's all I wish to say on the subject for the moment. Perhaps you will find something here to put before future Product Reviewers, when they submit their articles. My hope is that I have sparked a debate which will lead to an even higher standard for what is already a fine publication.

Yours sincerely,

Phil E. Cogar
P.O. Box 364, Narrabeen,
N.S.W. Australia 2101

I find myself in complete agreement with your four points. I'm sorry the FOR_C article didn't measure up.

Generally I'd just as soon do without "reviews". That's why we've used the label "User Reports". I don't really care if someone gave the product four stars — I want to know what it's like to use the product. Will it require some changes in my work habits? Does it seem to fit a certain design style better than others? Are certain unobvious tricks necessary to certain goals. If someone has spent enough time with a product to be qualified to evaluate it for other experienced programmers, then that person has also learned several things that aren't in the manuals. Why should I have to relearn those items if I decide to buy the product? The writer should give me the full vicarious benefit of his experience.

Here are some of my guidelines for anyone interested in writing a product related story.

Don't try to sell the product or your philosophy of how products should be designed, tested, marketed, packaged ... whatever. Instead, tell us what it does and doesn't do.

Keep the opinions to a minimum. If you give intelligent, experienced readers access to the facts that produced your opinion, they'll reach a similar (or at least reasonable) opinion on their own.

Don't be cute. I don't care how entertaining you think your struggle to remove the shrink wrap was, I don't want to waste time reading about it.

Don't guess. If you aren't certain about a particular issue, either find out or don't mention it.

Don't just list features. That's the role of vendor literature.

Do share all you learned in working with the product. If you include information inappropriate to my audience, I can edit it out. I can't edit in information.

I'm acutely aware that we very seldom get product-releated copy that fully measures up to these guidelines. We're always working on getting better copy. — rlw

To The C Users Group:

I am disheartened at the lack of truly advanced pioneering books in C programming. Particularly those of a scientific nature. Numerical Recipes in C and Numerical Software Tools in C are the only two that I have heard of, which are primarily argorithm'ic' books without instruction. Everyone seems to be publishing the same link lists, the same databases, and the same TODO lists. Just as in assembly language books one gets the same Ram disks, disk caches and clocks. That is not just book publishers either. Journals and magazines are doing the same thing. I cannot believe that the programming community lacks such expertise. When will publishers realize that enough is enough, and start producing books and articles of a truly advanced nature, like the one you had The Fast Walsh Transform. It is also time for a complete numerical methods book written for C programming in a common compiler (MSC TC) with full descriptions as one would receive in a course in numerical methods at a University.

Sincerely,

Jerry Rice
504 Eastland St.
El Paso, TX 79907

Maybe some qualified author (with a willing publisher) will hear your plea.

Why do publishers publish the same material over and over? Perhaps because it sells. One of our earlier issues (with several stories covering the fundamentals of device drivers) remains one of our most popular back issues. Perhaps device drivers are old-hat to you, but to many they remain a mystery. Most of our readers are expert programmers, they just aren't all expert in the same areas.—rlw