One way around this is to use a home-made routine in place of gets() -
(I name that routine Ngets(), myself) that provides a fgets()-like
buffer size limit, for safety (Buffer overruns are a good way to kill
off Bulletin Board software, to say nothing of embedded systems!)
Indeed a very good habit (I've learned to always transmit buffer sizes
to "Fill this buffer" type routines - and to always #define ANY buffer
size and use that [if not sizeof()] to tell the routine how big a buffer
is.

  Nothing like spending 12 hours debugging a weird crash to find HOW you
shot yourself in the foot.  Change a buffer size but don't change the
size in one call of 72, & you'll hate it <G>

  It's always far safer to build you own well-behaved tool, than use
existing buggy tools in the vain hope that their *known* shortcomings
won't bite you, IMHO.  YMMV here!

  Mark "You wouldn't use a screwdriver as a hammer, don't use gets()
when you can write Ngets() in 15 minutes tops", mwillis@nwlink.com

Philip Restuccia wrote:
>
> Hello:
>
> Speaking from 20 years of C programming experience: gets() reads
> characters
> from standard input into the buffer pointed to by its argument, until
> either
> a newline or EOF is encountered on the input.  The newline (if one was
> read)
> is discarded and the string is terminated with a null before gets()
> returns.
>
> The use of gets() is generally frowned upon since you have no control
> over
> the storage into the buffer you supply as argument.  If you happen to
> have
> misguessed the size of the buffer needed, and you attempt to input more
> characters than will fit in that buffer, well ... let's just say that
> that
> is not going to be a good thing. :-)
>
> fgets() (if available in the implementation) is generally preferred over
> gets() since it allows you to specify a maximum number of characters to
> read (regardless of whether a newline was seen within that amount).
>
>         Phil
>
> Michael J. Ghormley wrote:
> >
> > James Cameron wrote:
> >
> > > It's gets(), surely?  If it is the ANSI C function, it is defined as
> > > using getc() until it receives an end of line marker.  Are you sending
> > > characters followed by a carriage return?
> >
> > I have no knowledge of this flavor of C, but shouldn't he be sending a NULL
(0x00)
> > value to terminate an ASCII string?  Could that be the problem?
> >
> > Michael
>
> --
> Philip Restuccia
> Senior Principal Software Engineer
> Periphonics Corporation
> philip.restuccia@peri.com