I am delighted to see from your editorial in February 1991 C Users Journal that you have finally "accepted" E-mail! I think that the following would be "appropriate" as a suitable penance for your very tardy acceptance of a not-so-modern technology.

Get Robert Ward to place the Journal's E-mail address alongside the postal address, telephone, and Fax numbers, wherever they appear in the magazine.

Persuade your advertisers that the use of an E-mail address in their ads shows much more sophistication than a FAX number.

Finally, I believe that the combination of MCI Mail and the EMMA program (version 2.1) from the PC-MAG section of Compuserve, offers an easy to use and rather cost effective E-mail system for MS-DOS users within the US (and possibly elsewhere). As an MCI Mail user, I can address mail to FAX numbers (worldwide), Internet addresses, Telex numbers (worldwide), and most x.400 compliant E-mail systems (worldwide).

I use MCI mail whenever possible, even for personal purposes, because these services are always cheaper than an equivalent long distance telephone call (except 800 numbers), and always faster than paper mail!

Last but not least, you might note that I have MINIX 1.5 running on an ordinary (8088 based) IBM-PC. As intended, the system has the 'look and feel' of a primitive UNIX system. Thus it serves my needs quite nicely as an inexpensive tool for maintaining and expanding my recently acquired knowledge about UNIX systems. Accordingly, I would suggest that you keep this operating system in mind when editing articles for the Journal.

Kenyon F. Karl
P.O. Box 451,
N. Andover, MA 01845
Internet: 1771813@mcimail.com

I can assure you that the editorial staff has an open mind about MINIX and other variant operating systems. I still retreat to my IDRIS system when I get desperate for a UNIX-like environment. The only difference is that now I click on a Windows icon on my PC to start it up as an application. Whitesmiths, Australia sells MacIDRIS for the MacIntosh. I also saw a copy of MINIX boxed for commercial sale in the UNSW electrical engineering book store the other day. May the interesting alternatives never die. — pjp

Dear Robert,

Rodney Bates, in his interesting letter on C, Modula-2, and Pascal (January 1991) says "Also, no Pascal that I know of has separate interface and implementation modules." In fact, Borland's Turbo Pascal 5.0 (and later), the most widely known Pascal and usually acknowledged as the ad hoc standard for the PC world, does provide interface and implementation modules. Borland calls them _units_, but they work very much like the DEFINITION and IMPLEMENTATION modules of Modula-2. Furthermore, Turbo Pascal 5.5 and 6.0 offer a very creditable dose of object-oriented (no multiple inheritance, but some count that a blessing!) with a growing set of class librarires from Borland and outside vendors. Borland's Turbo Vision (included with version 6.0), for example, is a class library for event-driven, text-based GUI interfaced applications (mouseable, resizeable, draggable, tileable, cascadable windows; dialog boxes; radio buttons; persistent object streams; more). Borland has just launched a Pascal for Windows package, so it does seem that Pascal is flourishing in spite of Modula-2.

One reason for the delays in getting a standard Modula-2 could be that Nick Wirth himself quickly lost interest in the endlessly pedantic squabbling as aired in the MODUS (Modula-2 Users Society) Quarterly. MODUS itself proved to be an amateurish embarrassment, although there are rumors of a shakeup ahead. I still use and like Modula-2, but as Rodney Bates rightly points out, the lack of object-orientation and firm standards is a handicap. There are also limitations (acknowledged by Wirth) in the coroutine model for handling concurrent processes.

Finally, may I thank you publicly for sitting on my Language Standards Panel at the recent Software Development '91 conference. It may be significant that this year I could not get a Modula-2 spokesperson to join us.

Sincerely,

Stan Kelly-Bootle
Contributing Editor,
UNIX Review and Computer Language
25 Parkwood Ave.
Mill Valley, CA 94941

It's always nice to hear from one of the most entertaining writers in our field. It's also nice to get a balanced view on languages that often stir intense feelings. Thanks, Stan. — pjp

The language panel was fun. I was happy to participate, though frankly I'd have been less out of place in the audience. A language expert I'm not! — rlw

The Editor,

In the article "Pennies in Long Double" (CUJ, January 1991), an example is given of apparent bad code generation by Turbo C and Microsoft C.

The problem is that the following code fragments produce different values for i (98 in the first case, 99 in the second).

1) double d=0,99;
   int i;
   i=(d*=100,0);

2) double d=0.99;
   int i;
   d *=100.0;
   i=d;

In the article, the author stated that the ANSI standard requires that fragment (2) should produce the same result as fragment (1).

A close reading of the standard would not appear to bear this out however:

1) ANSI C does not require side effects (e.g. the storage of results into variables) until the end of the statement concerned. Thus the copying of the result of (d*=100.0) into d need not occur until after the storing of the result into i (see ANSI X3.6, X2.1.2.3).

2) The standard specifically allows floating point arithmetic to be performed in a greater precision than required by the expression #3.2.1.5). Thus the 'squeezing' of the result through a double (which produces the value of exactly 99 rather than 98.999etc) does not have to occur within a single expression statement.

Turbo C has an option (-ff-) which turns on 'strict ANSI rules' regarding floating point conversions. When this option is turned on, the code generates the same result in either case (99) at the expense of slower execution. This suggests that Borland agrees with the author's interpretation of the standard.

This example illustrates the fickleness of floating point code and the danger of relying on quirks of rounding (e.g. long double to double rounds, floating point to integer truncates).

The following fragment illustrates a similar problem:

int i=0; i=i+t;

That is, you could end up with:

1) i=0;
   temp=i;
   temp2=i+1;
   i=temp;
   i=temp2;

2) i=0;
   temp=i;
   temp2=i+1;
   i=temp2;
   i=temp;

Yours faithfully,

Tim Josling
5 Adam St
Bentleigh 3204
Australia

Sorry, I have to disagree with you on both points. You don't seem to realize that a semicolon constitutes a sequence point in C. All side effects you write between two sequence points must take place between those two points. No translator has the latitude you suggest. — pjp

Editor,

As "Contributing Editor" on networking, I must express my fustration in seeing our own magazine list unusable addresses for its editors.

In CUJ V9#5 PJ lists his address as pjp@plauger.uunet.com. Unfortunately that will not reach him. First, there is no domain uunet under the root domain com. The correct domain is uu under the route domain net. (uu.net). I have also seen in prior issues references to plauger.uu.net, however there is no subdomain plauger under the uu.net domain. The proper address is pjp%plauger@uunet.uu.net using FQDN format, or uunet!plauger!pjp using uucp format. (For those that must specify source routing we can confuse the issue as @uunet.uu.net:pjp@plauger if we must)

Take the whole letter with a very large :-)

Sydney S. Weinstein, CDP, CCP
Datacomp Systems, Inc.
syd@DSI.COM or dsinc!syd

I confess to an endemic confusion about how to form e-mail addresses. Occasionally, I make the mistake of following the advice of experts who prove to be much less expert than Syd. That has put me out of touch with parts of the world for weeks on end. Various systems I have to go through here in Australia choke on per cent signs or mixed forms as shown above. Writing all exclamation points is safest - provided the path doesn't get too long! E-mail is wonderful when it works, but sometimes it barely works — pjp

Editor,

As a new subscriber (April 1991 being my first issue), I would like to commend you on what already seems to be a very fine magazine. I was particularly interested in the April article, "Serial Communications with Turbo C," by Greg Chursenoff. Mr. Chursenoff was able to get a concise, yet practical synopsis of a rather messy topic. I have already begun referencing his work in my communications efforts.

However, I have noticed a subtle coding bug which exists in the listings for the article. On page 68, in the cleanup routine, the statement ch | = !IRQMASK should be ch | = ~IRQMASK to achieve the intended effect. The form that appears in the article uses the logical not operator which always returns an expression value of either zero or one. Since IRQMASK is defined as a non-zero constant, the logical not expression returns as zero. This, of course, leads to an or-assignment which will never change the contents of the ch variable. The corrected form employs the bit-wise one's-complement operator which inverts the mask as needed to restore the 8259 PIC Interrupt Mask Register. As indicated in the article, the PC interrupt structure is such that failing to disable the comm port interrupt mask during cleanup would rarely be fatal since writing zero to the 8250 Modem Control Register will inhibit all 8250 interrupts. Nevertheless, better safe than sorry.

Sincerely,

Roy Massie
3422 Ridge Crest Drive
Birmingham, AL 35216

Thanks. — pjp

Dear Mr. Plauger,

Let me begin by mentioning how great it is to have the current issue of The C Users Journal waiting for me in my mailbox every month.

As a computer hobbyist for about ten years, I have programmed in BASIC purely as a mental diversion and to quell some creative urge to create something from nothing. The idea being you start with an empty area and fill it in with code to achieve some meaningful result by way of a working program. And besides, it's fun.

Eight months ago I was introduced to the C and C++ languages using the Borland Turbo C++ platform and I gotta tell you this stuff is difficult!!! I am in awe with the likes of yourself, Ken Pugh, Rex Jaeschke and all the other contributors to your magazine. When I'm reading and trying to understand the subjects, I feel like I will never have the incredible amount of knowledge you have.

I'm going to be attending a local college (University of California at San Diego) to study at the formal level and was hoping you could share something with me and other readers who might be green beginners also. When you start a project, what steps do you take to create your direction? When I say project, I mean something on the smallish scale. Something a beginner or student would start. Do you write down your objectives or just type away? With a modular language such as C, do you write modules in any particular order or just follow the flow of the program? Is there a certain thing you do no matter what the project? What reference material do you use and what can you suggest to a beginner on how to become a competent C programmer? I guess I'm looking for the informal knowledge only years of daily use could provide. Is C even a good language to learn for recreational programming?

Thanks in advance for any thoughts you might offer. I know it probably sounds weird, but I would really appreciate it.

Keep up the good work. Your publication is simply first rate.

Sincerely,

Tom Neff
4352 1/2 Mississippi St.
San Diego, CA 92104

I can't distill 28 years of experience into one reader reply. You might try to dig up back issues of Computer Language magazine. I have been writing largely on this topic for over five years in that venue. If you want to learn about C specifically, however, you've already come to the right place. My general approach to designing programs is eclectic — whatever works. My overall approach, however, is based on divide and conquer. If a problem it too big to solve all at once, find some way to partition it. Eventually you get down to pieces that you can handle. The more successes you have at writing small pieces of code that work, the sooner you get down to manageable pieces. — pjp

Dear Mr. Plauger:

I found at least four instances in the May 1991, C Users Journal in which the universal constant, pi = 3.14159 . . ., was assigned its value discretely. That is, the authors of the listings defined the value of pi digit by digit. There is a simpler, more reliable way to introduce pi into any program, a way which assures the programmer that the assignment is accurate to the capability of the compiler/interpreter. Define pi using this statement:

pi = 4.0 * atan(1.0);

Sincerely,

Robert H. Penoyer
123 North New Avenue
Apartment D
Monterey Park, CA 91754

Yup. — pjp