On 22 Dec 98, 19:02  Peter L. Peres wrote:

 > gets will insert the NUL (not NULL) itself as per ANSI C, as soon as it
> sees an end of line character (usually '\n'). It is possible that it sees
> a '\r' instead. On a PC, pressing the rightmost Enter key should do this
> (?).

One might try ^J (i.e. Ctrl + J) aka '\n' aka 0x0a aka 10 aka aka LF
aka Linefeed,
or ^M (i.e. Ctrl + M) aka '\r' aka 0x0d aka 13 aka CR aka Carriage
return instead.

There is no end of line or "newline" character in ASCII, so CP/M,
MSDOS et al use a CR+LF pair for denoting a line separator. C,
coming out of the Unix world, uses a single LF for that purpose.  C
compilers for the MSDOS+Windows world have a "binary" in the
open function, which decides whether the library does a LF <->
CR+LF substitution during IO or not, in order to remain source
code compatible.

When implementing an gets or alike for an embedded system, I'd
interpret both CR and LF as "end of line", but would ignore any LF
after a CR, for compatibility reasons. I don't know and dont care
about gets (who uses gets?). When looking at input.c
(recommended as a gets replacement in the manual, if memory
serves me right), I notice that Ccs just looks for a simple 13 (==
CR == ^M) the get_string function. I guess gets does it no different.


--
      o      (     Wolfgang.Strobl@gmd.de (+49 2241) 14-2394
     /\        *   GMD mbH                       #include
   _`\ `_<===      Schloss Birlinghoven,         <std.disclaimer>
__(_)/_(_)___.-._  53754 Sankt Augustin, Germany ________________