Dear Sir:As a new subscriber I became aware of your upcoming special issue on connumications too late to meet the deadline for submittal. I see that one suggested topic is CRC code calculation. There is a problem with the CRC-16 code specified by X.25 that might cause programmers some grief and that might therefore warrant a paragraph or so in the special issue.
Section 2.2.7 of CCITT Recommendation X.25 (Red Book) specifies the use of a CRC-16 frame checking sequence (FCS). The sequence is specified exactly in 1) and 2) of Section 2.2.7 and examples are then given for typical implementations at the transmitter and at the receiver.
The typical receiver implementation in X.25 is missing an initial multiplication by x^ 16. If the receiver is constructed to exactly duplicate the sequence of steps specified in the typical implementation, all incoming frames will be taken to be errored.
The correct procedure, including the aforementioned multiplication, is specified in Section 2.7 of CCITT Recommendation Q.921 which deals with the integrated services digital network (ISDN). Although the descriptions are worded somethat differently, X.25 and Q.921 specify identical FCS algorithms. Careful reading of the wording in the two documents is required to reconcile the differences in grammatical structure which, at first glance, make it look as if the mathematical procedures differ.
This information is based on one early copy of X.25 and I have not had the opportunity to check for corrections in later editions. CCITT procedures generally, however, prevent changes to published recommendations between revision cycles.
Thank you for a fine magazine.
Sincerely,
Maynard A. Wright
6930 Enright Drive
Citrus Heights, CA 95621I haven't verified this problem, but it sounds like the kind of thing that gives programmers serious headaches. Thanks for the warning. —rlw
Dear CUJ:
Your Publisher's Forum columns in the April and May issues are identical. Is this deliberate? I ask only from curiosity.
The C Users Journal is a magnificant source of useful information and, like fine wine and cheese, seems to improve with age. You are all doing a great job and deserve the kudos which come your way.
Sincerely
Rich Shepard
113434 NE Sandy Blvd., NO. M3
Portland, OR 97238As one who is increasingly feeling his age, its nice to know age improves something.
Read on for more about the magically mystifying obfuscated code/Publisher's Forum performance. —rlw
Dear Editors:
Congratulations to Robert Ward and Don Libes for their magical feat in the April 1990 issue, the invisible "Obfuscated C Code Contest" results. My colleagues and I were enthralled for several minutes searching for the non-existent article. We were truly impressed at this feat of editorial wizardry, and wish to extend our applause to your staff as the winners in the best "Composite Effort" category.
In Good Spirit,
Philip Michaels
Software Engineer
Research & DevelopmentWhat would I do without good humored readers?
As I explained in last month's letters, the cover type and publisher's forum which appeared in the April issue appeared one issue early by mistake. The publisher's forum should have appeared in the May issue only, but in some deadline confusion also wound up in the April issue. (I was working on two issues at once — I guess my operating system doesn't support multi-tasking.)
The obfuscated code contest actually appears (as intended) in the May issue. The (very) bad puns appear in the June publisher's forum. —rlw
Dear C User Journal,
Allow me to praise you on a excellent magazine. I've always found something interesting and useful in it. The article on executable strings should be rated "DANGEROUS!" USE AS LAST RESORT ONLY!" There is no need for this with the compilers and assemblers available today. Some OSs will not allow a program to execute from the data area which makes the approach questionable even if you don't consider the maintenance nightmare it will cause. Most compilers place string literals in the data area. Given a compatible assembler, compiler, and linker, it's very easy to do it right. I believe it will be less expensive and easier to understand also.
To the Best Solution,
Frank Veenstra
24797 Metric Drive
Moreno Valley, CA 92387"Dangerous" is an understatement as far as I'm concerned. Didn't you notice the skull and cross-bones in the accompanying artwork?
While it's not a technique I endorse, I think understanding how "executable strings" work gives some insight into how pointers and pointers to functions work and illustrates how much control (and lattitude for abuse) the C programmer has. —rlw
Dear Mail,
In the May 1990 issue the article "Executable Strings" by James A. Kuzdrall stated that executable strings will work for the 80X86 large model only. It is possible to execute strings in any 80X86 memory model by casting the string to a far function pointer. See Listing 1.
Yours truly,
Rick Shide
Moore Data Management
S Hwy 100
Minneapolis, MN 55416-1519Dear Robert,
First I want to congratulate you on this excellent journal. Although I'm a very recent subscriber, I've enjoyed every minute reading it.
The "hot stuff?." J.A. Kuzdrall presented in his article "Executable Strings" in the May 1990 issue, drew my attention. I couldn't believe his ending paragraph, where he says: "This trick won't work with the 8086 family,... ..., unless the code is compiled using a "large" memory model (four byte pointers)". Being a Turbo C user, I thought there should be ways to implement this using a small memory model. The accompanying listing (Listing 2) shows how. So I say the trick can be performed with the 8086 family (I only can speak of Turbo C v2 although not as easy as stated in J.A. Kuzdrall article.
By the way, many thanks for a very early delivery to Belgium of your magazine.
Sincerely,
Francis Willems
Pastorijstraat, 102
2152 Wechelderzande.
BelgiumDear Mr. Ward,
Let me take this opportunity to thank you for your publication. As a programmer/analyst who has programmed in C for my entire career, I have not found any other journal or magazine which can compare. I am writing in response to a letter you published about Microsoft's C v5.1 malloc problem, Vol.8, Number 2, February, 1990, p.133.
Mr. Jim Schimandle was correct, until he tried to explain what MSC5.1 was failing to do. If you alter the test program to malloc( ) and then free( ) a set of buffers of a constant size, but rather than exiting, allow the user to change the size and then malloc( ) and free( ) again, you will find that the behavior described in the article happens when the buffer size used for the initial set of malloc( ) calls is greater than 32,758. This number was found by trial and error, starting with 32,767. The problem does not happen if your size for the initial set of malloc>( ) calls is less than 32,758. Your second set of malloc( ) calls can then use a size greater or smaller than 32,758 with no major side effects. Further testing has shown that the problem disappears when you use an initial buffer size of 65,500 or greater. The maximum buffer size you can malloc( ) is 65,516 which is significantly smaller than the largest unsigned integer of 65,535. I hope someday to automate a test to find all the initial buffer sizes which cause the problem.
All low level bit flippers who have adapted to the IBM PC platform know that MS-DOS works on a 64K segmented architecture (borrowed from the CP/M). We should be able to allocate memory in blocks of up to 64K (the largest integer value possible in an unsigned int). Finding the exact cause of this bug is impossible without accurate source code. I believe the problem may hinge on what the malloc( ) function does to collapse continguous unused blocks of storage in order to satisfy a new malloc( ) call. I originally thought that the problem was due to the size of the free block with MSCv5.1 misinterpreting the size of large free blocks. But since allocating very large blocks also appears to work, the problem becomes more complicated.
The bottom line for programmers using MSC5.1 is if possible avoid allocating blocks of memory larger then 32,758. Programmers should also avoid allocating memory and freeing it repeatedly (keep the memory allocated and use memset( ) when possible) because the mechanism MSC5.1 uses to collapse free space is a compromise between speed and fragmentation. The original letter provided an elegant solution of writing your own separate functions to allocate and free memory but this has many inherent risks that I would rather not face.
Once again, thank you for such a wonderful magazine.
Sincerely,
David Grey Stahl
1033 S. Queen St.
York, PA 17403Doesn't 32758 sound suspiciously like 2**16? Sounds to me like someone may have a short int arithmetic overflow. Thanks for a wonderful letter. —rlw
Dear Mr. Ward,
This is regarding book reviews, in The C Users Journal. Along with the review you should also print the address of the publisher of that book. This may not seem important to all those staying in U.S.A. but for all those staying in other countries where it is very difficult to get good C books. At least these fellows can then write to the publisher and order the reviewed book.
Why not print the address of all good C source book stores in your next issue?
Hope to hear from you,
Thanking you,
Yours sincerely,
Jaspal Singh
Post Box 4758
Riyadh 11412
Saudi ArabiaYour suggestion is well-taken, we'll try to include this information in the future. (Be warned, though, it'll take several months before the change works its way into the magazine.)
As for bookstores, I don't begin to know all the good technical bookstores, but if our readers will send their nominations, we'll share the list here in the letters section. —rlw
Dear Editor,
I am seriously looking for software libraries written in C that can do gridding to densley and irregularly spaced data (e.g. seismic data). I am a geophysicist and program in Microsoft C v5.0. I would like to generate a regular grid which could then be accessed through my programs for further manipulation and interpolation.
I am not interested in fancy displays or pop up menus, just to be able to generate the gridded data that can be read by other programs.
I have tried Quicksurf, which is a standalone program that is advertised in the geological magazines, it outputs DXF format for further manipulation with AutoCAD. I got around the problem by writing a utility to reformat DXF to a more grid-oriented format. The major hurdle is the copy protection. I want to be able to link the libraries to my programs and distribute them.
There is bound to be someone out there who has written a gridding routine and is willing to share (or sell) his/her software library.
Appreciate your assistance.
Sami Kurdy
P.O. Box 211 Sharjah
United Arab Emirates
Tel 9716 543000
FAX 9716 542000How about it? Has someone addressed this problem? If so, I think it might even make an interesting story. —rlw
Dear CUJ:
Since mention of "nude centerfold" and "swimsuit issue" both appeared in letters sections of the June 1990 issue, I'd like to point out that this magazine is read by people other than heterosexual males such as myself. I'd prefer that such comments not appear in a technical magazine; however, if they must, then I propose that Robert Ward be the first to bare all.
An avid reader,
Earl Fong
Island Graphics Corp
4000 Civic Center Drive
San Rafael, CA 94903I'm willing but I doubt it'll do much for circulation.
I think you've taken umbrage unnecessarily. The comments appeared in a letter from a reader who was (very cleverly I thought) poking fun at those who expect CUJ to be all things to all people. I can't even see any explicit sexist content. He said only nude and centerfold — there was no mention of the model's gender in either reference. Perhaps he had in mind a male model?
I'm sorry, but I will continue to print (without censorship) well-written letters which make a point that I think may be of interest to a substantial portion of my readership. If that offends you, so be it. —rlw
Dear Editors,
After having read my first issue of The C Users Journal (June, 1990), I am impressed with the editorial content of the magazine. I was happy to see that you devote a portion of the magazine to design methodologies. I particularly enjoyed Joe Celko's column on structure charts and hope that he will continue prosletyzing this technique in future issues.
I would like to point out that Mr. Celko's solutions for the "Magic grid" puts the reader on the "doorstep". Starting with Mr. Celko's solution, I found a grid that results in a quotient of exactly 10:
*837 15** **40 629*I found it interesting that the automated solution provides a good starting point (if not a perfect solution) from which to explore this problem further. I discovered some interesting properties about the domain of this problem that allowed me to reject certain solutions very quickly. Perhaps this suggests yet another methodology — computer assisted domain analysis?Sincerely,
Donald Koscheka
168 Intervale Road
Stamford, CT 06905Dear Sir:
As a brand-new subscriber I have to congratulate you for your beautiful and informative magazine and thank you for the invitation to participate in the dialogues that are taking place in The Journal.
I've just received the first issue and read this from beginning to the end, now for three times. The information you are distributing is highly interesting and I am sorry I haven't subscribed to your Journal earlier.
The article from Mr. Leor Zolman about the database program got my attention because of his clear language. I am only very sorry that I could not follow this from the beginning and wonder if there is some way to get his earlier articles in my hands. Please inform me about this subject, it will be very appreciated.
I hope that your Journal will have a lot of subscribers also in other countries and assure you that I will do my best to achieve this aim here in Turkey.
Meanwhile I look forward to your answer and information I asked for.
With best regards,
Istek Sitesi,
Block D, Kat 1, Daire 2
Virnasehir, Zip 33100
Mersin, TurkeyLeor's series appeared in four consecutive issues (April through July). At this writing, we still have all of these issues in inventory. Back issues are $7.50 each, $11.00 overseas. —rlw