I don't know if you have addressed this problem earlier in CUJ as I have started my subscription recently.

I am working in MS Window/SDK environment and would like to handle signals. However, I found out that I could access the signal SIG_FPE. I spoke to Microsoft tech. support but could not get any positive answers regarding signals or any other equivalent mechanism.

I would greatly appreciate it if you could provide me with some tricks or tips to signal handling in MS Windows environment.

Thanking you in advance for your response.

Sincerely,

Arun Kurdikar
107-B Boulevard
Elmwood Park, NH 07404

No standard mapping exists between the interrupts and traps of a given system and C-style signals — not even for any one operating system. If you really must field an interrupt on the 80X87, you're probably better off doing it with machine-dependent code. Otherwise, stick with the facilities provided by the operating system. Signals aren't nearly as nice as they at first appear. — pjp

Dear Sir/Madam,

Hey, I would like a copy of that AT&T catalogue advertised on pages 23-29 of the April 1992 issue, but that 800 number 'is outside my calling area.' Can you provide me with an address, an alternate phone number, have them send me a copy, or something? I regularly collect information both for internal use and perusal by members of our local C language special interest group during bimonthly meetings at BCIT, and my bet is that others have been stymied by similar lack of access to information. As an example, my bet is that many of us would like a comparison of AT&T's Buster to GHOST, and CUJ hasn't provided it — yet (hint).

Thanking you for your assistance in this matter.

Sincerely,

Vic Williams
606-6455 Willingdon Ave.
Burnaby, B.C., Canada
V54 4E4

AT&T tells us that the number for callers outside of the United States is (908) 580-6310. — dt

Dear Mr. Plauger:

The letter from Mr. James Cook (March 1992 issue) has also been a problem for our office in the development of our energy management system. We had started using a VAX 11/750 with the VMS operating system. Enclosed is the original test version of the inkey function that had to be developed to communicate character by character with the outside world, either via the keyboard to the user, or to the OPTO-22 systems in each of our buildings. We switched from the VAX to a 80386 micro-based system, using SCO XENIX for a variety of reasons (the complexity of the operating system, size, age, and replacement cost).

SCO XENIX also has the same problem communicating with the outside world character by character. Also enclosed is the inkey function that was developed for SCO XENIX. One of the requirements that we had was to be able to direct the input to inkey easily from any port that was specified. Thus, we have the chan argument to the inkey (chan) function to specify which device is being used. In the case of the XENIX inkey, if chan = 0, then the keyboard has been specified. In the case of the XENIX inkey the specified device must have stty raw set.

As you pointed out in your reply this type of function was "tailored to each system" in order to "hide the irregularity of the system". Our main software package has been compiled, linked, and run on each system with only supplying the appropriate inkey function. Thanks for a good journal.

Sincerely,

William W. Ryan, Jr., Ph.D., P.E.
Physical Plant Engineer
Associate Professor
Harding University
Box 462
Searcy, AR 72143

The code Dr. Ryan refers to is available with the code disk for this month's issue of CUJ. — pjp

Dear Mr. Plauger,

In James Cook's letter to the editor (CUJ March 1992) he states that the curses library function getch does not send the entered character(s) to the calling function until a newline is entered. In the curses library I use, single-character input mode is controlled using cbreak/nocbreak and raw/noraw. raw mode, as its name suggests, sends all entered characters, one at a time, to the calling function as normal text, including interrupt and quit characters; cbreak enables single-character input mode but does not affect interrupt and flow-control characters. If the calling function can't wait for operator input, getch can be made a non-blocking call by using the nodelay function. In this mode getch will return a --1 if no input is ready.

The following example program illustrates single-character input mode by changing the case of entered alphabetic characters and echoing the result. This program was written on an HP-9000 workstation running HP-UX and using the curses library supplied by HP. I don't know if this will solve Mr. Cook's problem on his VAX, although I think most curses libraries should offer similar capabilities. All of the curses functions mentioned above are referenced in Axel Shreiner's book Using C with curses, lex, and yacc. If Mr. Cook intends to port his application to a PC, he may want to look into the PC-curses library advertised on the same page as his letter in the March issue.

Chris Adamo
1 Willow Crest Way
Medway, MA 02053

Again, the code Mr. Adamo refers to is available on the monthly code disk. Sadly, the functionality you describe is not available on all systems. -- pjp

Dear CUJ,

I had an occasion to use Arkin Asaf's dprintf function (September 1990, p. 37) and wanted to tell other potential users of some problems I encountered, and my fix to them. Our programming team needed a function like this because a recent port to the IBM RS6000 revealed that their printf function would not zero pad for strings. (Their excuse was "complying with ANSI standards" — Ha!) For example,

printf(" [%012.12s] \n", "123");

[       123]

[000000000123]

Char[0]=va_arg(Args,unsigned char);

Char [0]=(char)va_arg(Args,int);

printf ("%c\n", 'C');

The other problem pertains to the float format when you are left-justifying your number. Consider this case

printf("[%-10.2f]\n", 123.123);

[123.12    ]

One more! I believe that this is an omission in PrintFloat (correct me if I'm wrong):

if (Format=='g')  /* line 446 or so */
 Format='e';
else
if (Format=='G')
 Format='E';
dputc (Format);
++*OutCnt; /* <- stick that in */

Thanks again,

Mr. Kelly Beard
Trendar Corporation
1655 Murfreesboro Rd., Suite C
Nashville, TN 37217

Once again, the code Mr. Beard refers to is available on the monthly code disk. Zero filling a string is a legitimate extension, since it defines otherwise undefined behavior. IBM has every right not to indulge in such extensions, however. And you are correct about the behavior of char arguments. Each is converted to an int argument, at least in the absence of a function prototype. — pjp

Dear People:

I have several questions about compliance with copyright law as it applies to software. The law seems to be clear — we don't use the work of others for our own gain without compensation of some sort to the originator. But application of that idea may be anything but clear. My assumption is that public domain software is a method of advertising the skill of the author and shareware is a method of testing market potential. The software is donated but with some expectation that the originator will benefit somehow.

Your masthead, like others, warns against reproduction. Then you make source code available on disks at a price that can allow little or nothing for the originator after disk production, handling, and shipping costs. What is the policy regarding use of that code? Does the policy differ for personal use and commercial use?

Borland's No-Nonsense statement is about as clear as legalese can ever be. But it can't be the attitude of all software owners. I have paid Borland for the use of their code. Though all my programming thus far has been a personal hobby, I would feel free to sell a program I write with Turbo C and using functions from some of their sample programs. But how diligent must I be to never include a function from some other source?

Most of your readers know all about compiling functions and collecting object code libraries. Unless some unusual measures are taken to prevent it, the origin of the function disappears even if there is no intent to hide the origin. Is there some protocol for crediting functions that has escaped my notice? And does it require a complete program for code to be of any value?

Sincerely yours,

Elvin E. Birth
135 Fairway Lane
Southern Pines, NC 28387

Robert Ward replies:

1. The general rule should be: don't use someone else's code in a product unless you have written permission from the author. This is especially true of code in the CUG library and appearing in our magazine, since the publication and distribution rights granted to us vary greatly from author to author.

2. Authors are not paid a royalty for code distributed on CUG disks or on our magazine code disks. The fee you pay for those disks is strictly a distribution fee. The distribution fee does not purchase any license to redistribute. You should be very circumspect about using any such code in a commercial product.

3. I don't know what to say about how careful you must be. It seems silly to worry about whether the common implementation of strlen has been coincidentally copyrighted as part of someone else's application, but I can't guarantee that some attorney would refuse to prosecute such a claim. My personal view: software authors, like those pursuing other intellectual crafts, deserve compensation for their creative efforts; but copyrights and patents, as defined for other works, just don't make much sense when applied to software. We need a new concept ... not just a hackneyed adaptation of feudal concepts.

PJP replies: I have a bit more faith in copyright law than Robert does — and so does the U.S. Congress. Perhaps we should tweak the lifetime a bit, since software seldom ages as well as Mickey Spillane. But otherwise, the law is right on the money. We need to protect the expression of an idea as embodied in executable code. For much the same reasons, I am staunchly opposed to patents. I even feel that the software patents issued to date should be rescinded, since most are ill-considered and indefensible.

I don't worry about whether my version of strlen infringes someone else's. The simpler a function, the harder it is to prove that the obvious expression of it is at all unique. On the other hand, I grow progressively more cautious as I re-express ever more complex functions. Beyond a certain point, I am more comfortable licensing good software than re-engineering it. Since I sell both code and words for a living, I am naturally all in favor of giving authors their due. — pjp

Dear editor:

As always, I read with great interest your editorial in the May 1992 issue of the C Users Journal. I would like to accept your invitation in that editorial to suggest a topic for a future article.

Several times a year I teach an introductory class in programming in C at the local state university. In addition to discussing the syntax of C, I always stress the need to make programs user friendly as well as fool- and fail-proof.

Since every introductory text in C programming starts of by teaching the use of scanf for user input, it never takes long before I find myself apologizing for the existence of such a misbegotten function which offers more opportunities for crashing a program than any other I am aware of.

Of course, scanf has the charm of being a quick and dirty input function which is excellently suited for short and simple demo programs that are useful in a classroom setting. Still, after telling the students to stay away from scanf in real life, the question remains, what else is there?

Combinations of gets or fgets with sscanf or atoi/atof are a way out, but still don't yield the safety and protection that a well-written program should provide.

I have written some short routines in the past for error-proof currency input and such, but I am not confident that those routines are as complete and straightforward as they could be. In the years I have been reading CUJ I don't remember seeing an article on the topic of reliable input procedures. I believe that many others, in addition to myself, would be interested in such an article. Would you consider this topic for a future issue?

Sincerely,

W.F.H. Borman
209 Logwood Drive
Evansville, IN 47710