#: 20865 S3/Languages
    26-Mar-95  02:04:43
Sb: #20864-#scanf() question
Fm: David Breeding 72330,2051
To: Bob van der Poel 76510,2203 (X)

 > I think that for problems like that, and many others, most C programmers
 > do not use scanf(). Instead, it is much easier to use gets() and atoi(),

That's the most logical solution, really, I just thought that perhaps there
might be some workaround.  Guess I'll do some rethinking on my technique.

Is this scanf() thing peculiar to our system or is this a problem for all
platforms?  Actually, this seems to be a real handicap for that call.

 > etc. BTW, a very useful function to have is cgets() and cfgets() which
 > converts the trailing CR in an string to a '\0'. Those trailing CRs can be
 > a real bother.

Yes, I've read your articles on this.. I have intended on starting an auxiliary
library for some of these things that have been left out, but just haven't
started.

Came across another oddity..  I've been working on a program which I first
wrote for the CoCo in B-09.  I've rewritten it for OSK in "C".  I had a
database of 315 entries, consisting of a date and, in this case, 6 integer
items each.  Being the lazy type, I wrote a filter that would open a text
(ascii) output file of this data.  It would enter a "1" for the menu option to
open a file, enter the filename, then read the database, one entry at a time,
printf("3\n") for menu option 3 each time and using printf(), enter the data.
Of course I'd pipe this into my program.

In the program itself, for the file open, it uses fgets() to get the data
filename.  The individual field entries were input using scanf()-getchar() to
get the date and then the same to get each individual entry.

This method worked flawlessly on my OSK machine.  I thought I'd try to check
everything out on the CoCo, but this so far has simply refused to work. Both
the program and the filter were compiled from the exact same source, except for
some variations in the termcap initialization.

The process on the CoCo appears to me to be shooting data to the program and
losing some, sending them out into the "bit bucket" or something, as, when it
gets back to the menu, it is not getting the "3" option, but sending it to
another option, picking up some number entry on down the line.

It's gotten me aggravated.  The thing _should_ work -- it does in OSK, but
doesn't on the CoCo.. I think there's some little thing wrong with it's system
(since it works in OSK).. I'd like to know what gives with it.. Wacky buffering
on the Coco??

There are 2 Replies.