Path: utzoo!utgpu!water!watmath!clyde!ima!haddock!suitti
From: suitti@haddock.ISC.COM (Steve Uitti)
Newsgroups: comp.sys.mac.programmer
Subject: Re: LSC 3.0 scanf deletes
Keywords: delete, scanf
Message-ID: <5794@haddock.ISC.COM>
Date: 3 Aug 88 19:36:52 GMT
References: <2559@pt.cs.cmu.edu> <587@helios.ee.lbl.gov>
Reply-To: suitti@haddock.ima.isc.com (Steve Uitti)
Organization: Interactive Systems, Boston
Lines: 69

In article <587@helios.ee.lbl.gov> beard@ux1.lbl.gov (Patrick C Beard) writes:
>In article <2559@pt.cs.cmu.edu> phd@speech1.cs.cmu.edu (Paul Dietz) writes:
>>I'm tired of fighting this one. Does anybody know how to delete
>>characters when you make a mistake typing during an LSC scanf?
>>Paul H. Dietz
>
>The answer to your question is, DON'T USE SCANF!  I have always hated
>the way scanf treats the user who assumes he can edit his command line.
	Under UNIX, the user typically can edit the command line.  The
Mac interface doesn't really have a command line, so scanf must
implement one.

>A better approach to getting lines of input and parsing them from the user
>is to use gets() and then sscanf().  For example:
>float foo()
>{
>	float in_value;
>	char buf[80];	/* overconservative */
>
>	printf("enter ... ");
>	gets(buf);	/* user can use backspace to edit */
>	sscanf(buf,"%f",&in_value);
>	return(in_value);
>}

	Under UNIX, scanf lets you edit stuff.  Trouble is, if (for
example) input is redirected from a file, and the pattern scanf wanted
didn't exist in the file, it would infinite loop.  This is bad.  One
more step - "gets" doesn't do bounds checking.

	Most C compilers still do all floating point with doubles.
For exmple, most compilers still actually convert floats to doubles when
passing values to/from subroutines.  I don't know offhand if LSC does this.

#include <stdio.h>		/* define stdin */
#define BS 80			/* often good enough */
double
foo()
{
	double in_value;
	char buf[BS];

	printf("enter ... ");
	if (fgets(buf, BS, stdin) == NULL) {
		/* handle the EOF error */
	}
	if (sscanf(buf, "%lf", &in_value) != 1) {
		/* handle the parsing error - expected one conversion */
	}
	return in_value;
}

	Programs should be written such that they can't over run
buffers.  When (not if) errors happen, they should be handled
gracefully.  All of them.  Another of the problems with sscanf (the
only remotely useful function in the series) is that it doesn't tell
you much about why it couldn't do something (if it even tells you that
it couldn't do something).  Thus, not only do I never use "scanf" or
"fscanf", I seldom use "sscanf".

	The LSC standard C library isn't the most robust.  It does
"seem to work" for most things, and the "console" window is utterly
painless.  The compiler itself does seem to be robust, produces code
that runs pretty quickly, and produces it VERY quickly.  If I were to
write Mac applications, there wouldn't be a second choice development
environment.  (A fully blown Mac II with two monitors and LSC 3.0 is
really hard to beat).

	Stephen Uitti