C/C++ Users Journal 1990 - 1995/CUJ.iso/unix/1990.txt

Text File | 1996-02-07 | 3MB | 96,735 lines

We Have Mail
Dear Mr. Ward:
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 [phone].
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 c